Accessing CA Datacom data using the TIBCO Object Service Broker rules language is similar to accessing TIBCO Object Service Broker data. The main difference is in the way CA Datacom interprets the request.
The following sections outline the differences encountered while using rules and point out normal TIBCO Object Service Broker rules behavior to consider when building applications.
If you issue a TIBCO Object Service Broker EXECUTE statement within a main (parent) transaction, it creates another (child) transaction stream, to a maximum of ten streams. The number of streams allowed in a TIBCO Object Service Broker transaction depends on the TRANMAXNUM Execution Environment parameter, which has a default of nine streams. Each transaction stream in TIBCO Object Service Broker that accesses CA Datacom data requires its own server thread.
The SELxx CA Datacom commands are used to retrieve data from CA Datacom for each retrieval statement (GET or FORALL) in your rule.
When TIBCO Object Service Broker runs in browse mode, no locks are taken in CA Datacom. When TIBCO Object Service Broker runs in update mode, the server retains an image of all the occurrences read (CA Datacom imposes a primary exclusive locking limit of 9999 occurrences). When the update to the occurrence completes, the server re-reads the occurrence that is being updated, and if the image matches the image originally retained, the occurrence is replaced or deleted. If the images do not match, the update is not done and LOCKFAIL is signalled.
A FORALL statement returns rows to TIBCO Object Service Broker in the order in which CA Datacom passes them. If you require a different order, you must include an ORDERED clause in your FORALL statement.
When running in update mode, the equivalent of an exclusive lock is applied to the row being updated. To accommodate the largest number of rows to be updated within a single transaction, increase the size of the EXCTLNO parameter in the CA Datacom master list.
If the Duplicate Master Keys field is set to N, the row is re-read, checked against its previous image, and if the images match it is replaced or deleted. If the
Duplicate Master Keys field is set to Y, only one row at a time is returned to the Execution Environment and the last row retrieved is replaced or deleted.