Sequence Number Caching

The iProcess Engine server processes use sequence numbers extensively in doing their work. A sequence number is simply a unique identifier for an object, such as a case number, wait ID, or request ID.

Sequence numbers are generated on an “as required” basis by calling a stored database procedure that accesses the sequence table. (This table contains an identity column. The procedure inserts a row into the table, returns the value of the identity column, then deletes the row.)

However, getting sequence numbers directly from the database in this way can create a performance bottleneck, because while one process is requesting a number it must block any other process from attempting to do so.

To minimize the effect of this bottleneck, you can assign caches of sequence numbers to a process, using process attributes. The process will get a sequence number from its cache when it needs one, and will only need to access the database to refresh the cache when it has run out of numbers.

The following table shows:

The different sequence numbers that can be cached, and the process attributes that you need to set to cache them. (See Administering Process Attributes for more information about process attributes and how to set them.)
The different processes that use each sequence number.

Sequence number (Process Attribute)

Process Name

BG

RPC_POOL

SWBATCH

WIS

Case number (CNUM_SEQ_CACHE)

No, unless the system makes heavy use of sub-procedures.

Yes

Yes

Yes - used when starting new cases from TIBCO iProcess Workspace.

REQ ID (REQID_SEQ_CACHE)

Yes - A REQ ID is needed for each work item that is sent out.

Yes

Yes

Yes - used when starting new cases from TIBCO iProcess Workspace.

Wait ID (WIS_INDEX_REFRESH)

Yes, if waits are used in procedures.

No

No

No

Note: If you use sequence number caching:
Gaps may appear in the value of the sequence numbers. For example, if the BG process caches 50 REQ IDs when it starts up, processes one NEWCASE instruction, and then shuts down, the unused REQ IDs (2 to 50) will be lost.
It is possible for a lower case number to be started after a higher case number. For example, suppose that a WIS has 50 case numbers (1 to 50) cached, and a user uses SWUTIL CSTART, which are located in the SWDIR\bin directory to start a case. The case will have case number 51 - the next available number in the sequence. However, if a user then starts a case through the WIS, that case will have case number 1 - the next available number in the cached sequence. Thus, the start date/time for case number 1 will be later than the start date/time for case number 51.