What is the use of Critical Section Groups in BW ? what is the need of Synchronization for Shared Variables? Scope of Synchronization in CS Groups? How to use CS groups with no performance implications?

Critical section groups are used to synchronize process instances so that only one process instance executes the grouped activities at any given time as shown in below screenshot-1.

In general, concurrently running process instances does not wait for the completion of other instance as shown in below screenshot-2.

Any concurrently running process instances that contain a corresponding critical section group wait until the process instance that is currently executing the critical section group completes as shown below.

 Screenshot-1

How Synchronization works with Critical section groups:

Multiple process instances can potentially access and assign values to Shared Variable resources, the Lock shared configuration object(by referencing shared configuration in configuration tab of the group) and critical section group allow you to synchronize access to Shared Variable resources.

Scope of Synchronization:

Critical section groups can be used to synchronize all process instances for a particular process definition in a single process engine or multiple process definitions or across multiple process engines by selecting the scope as Single Group or Multiple Groups in configuration pane.

What is the need of Synchronization:

Without a mechanism for locking, a process instance could update the value of a variable while another process instance is attempting to read the value. This would result in an unpredictable value for the variable.

You should use critical section groups to contain the Set Shared Variable and Get Shared Variable activities.This ensures that only one process instance attempts to assign a value to the variable and ensures that no process assigns a value to the variable when the current process attempts to read the value.

Best practices to use Critical Section Groups: 

There may be performance implications when using these groups. In general, you should use the following guidelines when creating critical section groups:

• Keep the duration of a Critical Section group as short as possible. That is, put only a very few activities in a Critical Section group, and only use activities that execute very quickly.
• Do not include any activities that wait for incoming events or have long duration, such as Request/Reply activities, Wait For activities, Sleep activities, or activities that require a long time to execute.
• Avoid nesting Critical Section groups. If you must use nesting, ensure that Lock shared configuration resources are used in the same order in all process definitions.Deadlocks can occur if you do not specify the Lock resources in the same order in nested Critical Section groups for all process definitions.

                                                       Screenshot-2

Read more...

Iprocess engine architecture: Foreground Processes- Mbox Set

• The Mbox Sets are responsible for communicating information between the foreground and background processes. 
• The Mbox messaging system stores and processes messages from Tibco iProcess Client or Tibco iProcess Engine requests. 
• Mbox sets comprise of one or more message queues.

The messaging system used:-

In the UNIX Oracle and Windows Oracle versions, Oracle AQ. This is a transactional messaging system provided by the Oracle database.

In the UNIX DB2 and Windows SQL Server versions, Staff ware's own transactional messaging system, which uses database tables provided by the DB2 or Microsoft® SQL Server database.

For detailed information on other foreground processes CLICK HERE

Read more...

Iprocess engine architecture(contd): Responsibilities of Foreground Processes

Work queue server(WQS):

The WQS is responsible for providing a complete list of work queues on the system, along with the RPC addresses (RPC number and machine name) of the WIS that handles each queue.

It contains the list of all the users and groups and controls who has access to each queue WIS Mbox Daemon  (WISMBD) RPC listeners  (RPC_TCP_LI and RPC_UDP_LI) RPC pool server  (RPC_POOL).

Work Item Server(WIS):

The WIS processes cache the contents of the work queues and provide lists of work items to TIBCO iProcess Clients.

The WIS processes concurrently produce messages (under transaction control) to be placed in the background Mbox set.

Each WIS process receives messages from the WISMBD. These will be stored temporarily in an in-memory buffer (per physical work queue) for later retrieval when the WIS performs an update from the in memory box.

WIS Mbox Daemon  (WISMBD):

It is  responsible for dequeuing/reading the messages from the WIS Mbox sets and passing them to the appropriate WIS that is handling the item.

RPC listeners:

For each user that logs into Staffware using the TIBCO iProcess Client, a connection to a swrpcsvr pool process is  allocated by the listener.

RPC pool server  (RPC_POOL):

These manage and allocate the RPC connections. For each user that logs into Staffware using the TIBCO iProcess Client, a connection to a swrpcsvr pool process is allocated by the listener. Each pool process maintains a pool of connections.

To know about foreground processes CLICK HERE

Read more...

Iprocess engine architecture(contd): Foreground Processes

ForeGround processes are responsible for communicating with Tibco iProcess Clients and for passing any Tibco iProcess Client requests such as released work items to the background area for processing.

Processes that operate in the foreground:-    

• Work Queue Server ( WQS)
• Work Item Server(WIS)
• WIS Mbox Daemon  (WISMBD)
• RPC listeners  (RPC_TCP_LI and RPC_UDP_LI)
• RPC pool server  (RPC_POOL)

For detailed information on these foreground processes CLICK HERE

Read more...