Copyright © Cloud Software Group, Inc. All Rights Reserved

Using Rules to Access Tables

Accessing external DBMS data using the rules language is similar to accessing TIBCO Object Service Broker data. The following sections outline the specifics encountered while using rules, and also point out normal TIBCO Object Service Broker behavior that you must consider when building applications.

Use the following sections in conjunction with TIBCO Object Service Broker Programming in Rules, which describes TIBCO Object Service Broker rules language statements and coding.

Retrieval Processing

A single cursor is used to retrieve data from the external DBMS for each retrieval statement (GET or FORALL) in your rule.

•	If the BROWSE flag is set to Y, no locks are taken. If the BROWSE flag is set to N, locks are taken on all external tables accessed via the FORALL statement. Also, if a subview against an SLK table is used, locks are taken according to the behavior warranted by the subview's lock mode setting.

•

If the server parameter SERVERORDERS=N, a GET ...ORDERED statement retrieves all data that satisfies the selection criteria and sorts it in the Execution Environment before returning the first occurrence that meets the selection criteria. If the server parameter SERVERORDERS=Y, the ORDERED clause is passed to the external DBMS.

GET Statement

A GET statement retrieves the first occurrence in the SLK table that satisfies the specified selection criteria.

FORALL Statement

A FORALL statement is a looping construct that processes a set of occurrences. The body of the loop consists of the statements to be executed for each occurrence satisfying the selection criteria. FORALL statements can be nested provided that they refer to different TIBCO Object Service Broker table parameter instances.

Occurrences are returned to TIBCO Object Service Broker in the order in which the Gateway passes them. If you require a different order, you must include an ORDERED clause in your FORALL statement or mark the relevant fields via the Table Definer.

Replace (Update) Processing

For the TIBCO Object Service Broker occurrence being replaced, all parameters and primary keys, with the AND logical operator between them, are used to make up the criterion describing the rows to replace in the external DBMS.

If the SLK table is defined with only data parameters and/or fields that result in an empty SET clause in a REPLACE statement, that REPLACE does not occur and an error message is produced.

Insert Processing

At insert time, all parameters and fields of the SLK definition except for those marked with VRT=V, W, M, 1, 2, or 4 are part of the column list of the INSERT statements submitted to the external DBMS.

Delete Processing

This is the same as Replace (Update).

Transaction Streams and Gateways

If you issue a TIBCO Object Service Broker EXECUTE statement within a parent transaction, a child transaction stream is created. The number of streams allowed in a TIBCO Object Service Broker transaction depends on the TRANMAXNUM Execution Environment parameter. Each transaction stream accessing SLK data requires its own gateway.

Ensure your system administrator is aware of the number of gateways required to accommodate all transaction streams accessing data in a single transaction.

Using TRANSFERCALL or DISPLAY & TRANSFERCALL statements in a rule minimizes the number of Gateways an application could require and reduces the possibility of locking contentions in the external DBMS.

See Also

TIBCO Object Service Broker Parameters for your operating environment for information about the TRANMAXNUM Execution Environment parameter.

Copyright © Cloud Software Group, Inc. All Rights Reserved