Sync Modes

Set Sync Command

The Fabric SET SYNC command is used to define the synchronization mode of an instance from source systems. The default value is On.

Syntax:

• SET SYNC [SYNC MODE];

Sync Modes

Note that the sync returns an error message when a source is not available. To change this, use the set ignore_source_exception true command.

Sync On Protection

Sync On Protection improves the response time of multiple GET LUI requests on the same LUI and Fabric node. For example, when executing a stress test by running a Web Service with the same LUI on multiple threads.

In principle, since each request requires a write lock in the LUI's MicroDB, multiple requests on the same LUI and Fabric node are executed sequentially if their Sync mode is set to ON. This means that even when LUI populations are not run, a short check can take a long time before the last GET is successful.

To avoid checking each LUI, Fabric implements Sync mode (Sync is set to ON) only on the first GET request on the LUI. Remaining requests are executed in parallel to the first request, and are executed with the Sync mode set to OFF.

SYNC_PROTECTION can be edited in the config.ini file:

1. The default value is zero. When Sync is set to ON, Fabric implements the Sync only on the first request.
2. If this parameter is set to -1, Sync On Protection is disabled and Fabric implements the Sync on each request. All requests have Sync set to ON in this case.
3. This parameter can be set in milliseconds. For example, if set to 1000, all Sync requests executed on the same LUI and Fabric node during the 1000ms after the first request run with the Sync mode set to OFF. After 1000ms, and until the first GET request on the LUI is completed, Fabric sets the Sync mode to ON.

SYNC_PROTECTION can be disabled on the session level using the SET SYNC_PROTECTION=off command.

Fabric Studio Server Configuration - Force Upgrade Post Deploy Checkbox

This checkbox defines the Sync mode of the first GET of each LU instance (LUI) after the LU is deployed to the server:

• If checked, the Sync mode is set to Force.
• When unchecked, the Sync mode is set to On.

Notes

• Checking / unchecking the Force Upgrade Post Deploy checkbox impacts the LU only after redeployment of the LU to the checked / unchecked Fabric server. It does not impact the LU instances retroactively.
• Sync mode is set to Force only for the first GET of each LUI after the redeployment of the LU.
• Sync mode is set to Force for the first GET of each LUI even if the Force Upgrade Post Deploy checkbox is later unchecked. The LU is redeployed, and the instance is not synchronized while the Force Upgrade Post Deploy checkbox is still checked.

Example 1

• Set the Sync Method of the Customer LU to None.
• Get Customer 1.
• Update the source DB of Customer 1.
• Check the Force Upgrade Post Deploy checkbox of the Fabric development server and redeploy the Customer LU to this server.
• Get Customer 1 again. The customer is synchronized and their data is updated since the Force Upgrade Post Deploy checkbox set the sync mode to Force.
• Update the source data of Customer 1 again.
• Get Customer 1 again. This time Customer 1 is not synchronized since the Sync mode is set back to On for the Customer after the first sync that was initiated by checking the Force Upgrade Post Deploy checkbox.

Example 2

• Set the Sync Method of the Customer LU to None.
• Get Customers 1 and 2.
• Update the source DB of Customers 1 and 2.
• Check the Force Upgrade Post Deploy checkbox of the Fabric development server and redeploy the Customer LU to this server.
• Get Customer 2 again. This Customer is synchronized and their data is updated.
• Uncheck the Force Upgrade Post Deploy checkbox of the Fabric development server and redeploy the Customer LU to this server.
• Get Customers 1 and 2 again:
  • Customer 1 is synchronized since this is their first GET after checking the Force Upgrade Post Deploy checkbox, even though this checkbox was later unchecked.
  • Customer 2 is not synchronized since it was already synchronized after checking the Force Upgrade Post Deploy checkbox.

Click for more information about the Get LUI Fabric Command.

Get Sync Mode

The Fabric UserCode class holds the method that returns the Sync mode set for the current session:

public static String getSyncMode();

This method can be invoked by a Decision function.

For example, if the Sync Mode is Force, then return True to sync the instance. Else, do not sync the instance.

To view the list of Fabric APIs, click http://[Fabric IP address]:3213/static/doc/user-api/index.html.

Always Sync

Starting from Fabric 7.0, this feature is replaced by SET SYNC_ON_DEMAND = ALWAYS.

Sync On Demand

The purpose of a Sync On Demand mode is to reduce the time spent by Fabric performing the LUI sync by synchronizing only the relevant data. In this mode, the sync is performed only on tables that are a part of the executed SELECT statement and their parent tables. The sync follows the standard Sync mechanism rules that are based on a LU predefined sync method and sync mode.

The logic of the Sync On Demand is as follows:

• Performing the GET command doesn't trigger the instance synchronization, as the synchronization is done in SYNC OFF mode. If the instance doesn't yet exist in Fabric, a full sync is performed.

• When executing the SELECT statement on LU tables, the evaluation is performed whether a sync is required or not. The evaluation is done only for the LU tables and their populations in the SELECT statement and for their parents up to the Root table. The synchronization logic follows the standard Sync mechanism rules that are based on a LU predefined sync method and sync mode.

• When executing the SELECT statement on LU business tables, the evaluation is performed on a business table and its parents.

• Sync On Demand can run in 2 different modes as follows:

  • When Sync On Demand is set to true, every table can be synchronized only once per each GET, even if several SELECT statements were executed on the source table and it was changed in between.
  • When Sync On Demand is set to always, every table can be synchronized on each SELECT, assuming the sync conditions are met.

• Sync On Demand is also supported when AUTO_MDB_SCOPE is set to true (the 'No Get' mode).

Note that an implementor should manage the transaction efficiently. Thus when a Web Service or GraphIt invokes several SELECT statements on the same LU, it is under the implementor's responsibility to manage the transaction in order to minimize the number of writes into the MDB Storage.

Syntax:

• SET SYNC_ON_DEMAND = [TRUE/FALSE/ALWAYS];

To define a Sync On Demand mode either:

• Set the SYNC_ON_DEMAND parameter of the config.ini file to True. The default value is False.
• Run the SET SYNC_ON_DEMAND=TRUE command to set it to True on the session level.

Sync On Demand Examples

Example 1: Sync On Demand = TRUE

• Perform GET LUI.
• Select from the CASES LU table. As a result:
  • Fabric checks whether sync should be performed (based on sync mode and sync method). If it should, the SELECT statement triggers a sync of the selected table and its parent tables according to the LU Schema.
  • For the given schema, the select from the CASES LU table triggers the sync of CUSTOMER, ACTIVITY and CASES LU tables.
• Select from the CASE_NOTE LU table. As a result:
  • The CUSTOMER, ACTIVITY and CASES LU tables are not synchronized as they were already synchronized once for this GET command. Only the CASE_NOTE LU table is synchronized.

Example 2: Sync On Demand = ALWAYS

• Perform GET LUI.

• Select from the CASES LU table. As a result:

  • Fabric checks whether sync should be performed (based on sync mode and sync method). If it should, the CUSTOMER, ACTIVITY and CASES LU tables would be synchronized.

• Select from the CASE_NOTE LU table. As a result:

  • Fabric checks whether sync should be performed (based on sync mode and sync method). If it should, all 4 LU tables - CUSTOMER, ACTIVITY, CASES and CASE_NOTE - would be synchronized.

Example 3: Several SELECTs in a Web Service or GraphIt

• Set Sync On Demand to either true or always, whatever is required.
• Perform GET LUI.
• Begin the transaction.
• Perform all the required SELECT statements:
  • On each SELECT, Fabric checks whether sync should be performed (based on sync mode and sync method). If it should, the relevant tables are synchronized - as per the above logic.
• Commit the transaction.