Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved


Chapter 6 Manipulating Data in a Table : Committing Changes

Committing Changes
Tables are not actually updated until one of the primary commands that commits the changes is issued from the primary command field. These commands are:
Using PF3 also commits changes.
Committing Changes Using the Table Editor
To commit changes and continue with your editing session, use the primary command SAVE. This commits changes without exiting the current session. To commit changes and exit to the workbench, press PF3.
The Table Editor displays a message at the bottom of the screen to indicate whether the changes are committed. For example, you see a message similar to: Updates to table ”EMPLOYEE(NORTHWEST)” saved. When changes are committed, they are saved in the ascending order of the primary key.
When changes are not committed, a message at the bottom of the display screen gives a reason for the failure and the Table Editor positions the cursor where corrections are required.
Committing Changes Using the Single Occurrence Editor
To commit changes to an occurrence, press PF3 or use the primary command SAVE. In either case, the new occurrence or the updates to an existing occurrence are committed, the table is updated, and the editing session is terminated.
Committing Changes Using Rules
At the end of every transaction, TIBCO Object Service Broker implicitly commits changes to the database made since the last synchronization point. Synchronization points can be established using the COMMIT and ROLLBACK statements from within a rule.
Understanding EES Table Considerations
This section defines EES tables and describes the procedure for processing them.
Definition
When the table type in the table definer is initially changed to EES, Object Service Broker adds two predefined permanent fields to the bottom, as shown here:
The field @@UPDATE_COUNT maintains integrity of the table data.
The field @@REF_COUNT contains a count of the number of times any given row in the table has been referenced.
Do not modify the definitions of those two fields, which must always remain as the last two fields in the table definition. If they are absent, Object Service Broker rejects access to the EES table.
Processing
Because EES tables can be shared in a multiuser Execution Environment, although their processing is similar to that of SES and TEM tables, some changes are necessary to maintain data integrity. Read on for the details.
Table Access
For a nonupdate processing to an EES table, Object Service Broker obtains a shared global lock for all the EES tables for the duration of the request. Whenever a row in the table is referenced by a nonupdate request, Object Service Broker increments the field @@REF_COUNT by 1.
Updates
For an update processing to an EES table, Object Service Broker obtains an exclusive global lock for all the EES tables for the duration of the update request. That is, once control is to return to the processing rule, Object Service Broker releases the lock.
Insertion of Rows
To insert a row in a table in addition to normal processing of the fields, Object Service Broker sets the @@UPDATE_COUNT and @@REF_COUNT fields to 1.
Replacement of Rows
To replace a row in a table, if the field @@UPDATE_COUNT exists in the replacement buffer, Object Service Broker compares it with the value in the actual table data. Depending on the result, either of the following occurs:
If the comparison succeeds, Object Service Broker replaces the row in the actual table data and increments the fields @@UPDATE_COUNT and @@REF_COUNT by 1.
If the comparison fails, Object Service Broker raises a LOCKFAIL exception and no replacement occurs.
If the field @@UPDATE_COUNT does not exist in the replacement buffer, Object Service Broker replaces the row in the actual table data and increments the fields @UPDATE_COUNT and @@REF_COUNT by 1.
Deletions of Rows
To delete a row in a table, if the field @@UPDATE_COUNT exists in the deletion buffer, Object Service Broker compares it with the value in the actual table data. Depending on the result, either of the following occurs:
If the comparison fails, Object Service Broker raises a LOCKFAIL exception and no deletion occurs.
If the field @@UPDATE_COUNT does not exist in the row buffer, Object Service Broker deletes the row.
Example: How the @@UPDATE_COUNT Field Maintains Data Integrity
Consider two transactions, A and B, both of which are attempting to update row X in an EES table. Assume that row X is currently in its initially inserted state, that is, fields @@REF_COUNT and @@UPDATE_COUNT are set to 1.
To maintain integrity, the rules for processing the table must read the data row before attempting to replace it, as follows:
Transaction A gets row X in its row buffer: The field @@UPDATE_COUNT is 1 and the field @@REF_COUNT is 2.
Transaction B gets row X in its row buffer: The field @@UPDATE_COUNT is 1 and the field @@REF_COUNT is 3.
Transaction A updates the data in its row buffer and replaces the row. Since UPDATE_COUNT is 1 in both its row buffer and the table data, the replacement succeeds. Accordingly, the field @@UPDATE_COUNT becomes 2 and @@REF_COUNT becomes 4.
Transaction B updates the data in its row buffer and replaces the row. Since field @@UPDATE_COUNT is 1 in its replacement buffer and is now 2 in the actual table data because of the replacement operation by transaction A, the replacement fails. Object Service Broker raises a LOCKFAIL exception.
See Also
TIBCO Object Service Broker Programming in Rules for information on the COMMIT and ROLLBACK statements and synchronization of the database.

Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved