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


Chapter 2 Understanding Transaction Processing : Sample Transaction

Sample Transaction
 
Task A The transaction requests data from a table
This request can be a GET or a FORALL on a table. The following occurs:
1.
The Execution Environment sends the request to the Data Object Broker requesting a logical shared-lock on the rows being accessed.
2.
If the required data pages are already in the buffers, they are available for use. If the pages are not in the buffers, the Data Object Broker retrieves them from the Pagestore and loads them into the buffers.
3.
4.
Task B The transaction performs an update
Update requests include:
During the update request, the following occurs:
1.
If no other transaction has a shared-lock on the rows being updated, the Execution Environment stores the updates in its intent list.
2.
An exclusive lock is requested for the updated rows. This means that no other transaction can obtain a shared-lock on the rows until the transaction terminates.
The data is not yet physically changed, and is not until a commit is issued. The Execution Environment keeps track of the changes, however, to ensure integrity and consistency are maintained.
Task C A commit command is issued
The following occurs after the commit command is issued:
1.
2.
The Data Object Broker writes the intent list to the redolog. This operation guarantees that all committed updates are written to the database.
3.
The Data Object Broker updates the data pages in the resident page manager buffers. This ensures that these new database updates are reflected in future accesses to the same data by other transactions.
4.
If an updated segment reaches its predefined capacity threshold, that is, it is nearing full capacity, warning messages are sent to the operator console.
5.
The Execution Environment is notified to proceed with the application. It clears the intent list, but not the database locks that are held by the Data Object Broker, and continues execution of the application.
6.
If a checkpoint is required, the Data Object Broker invokes its asynchronous checkpoint processor, which writes all the updated pages to the journals and the Pagestore.
7.
If the current journal fills up during a checkpoint, the Data Object Broker starts the spin process and switches to the other journal.
Task D The transaction ends
The following occurs:
1.
The Execution Environment passes the updates left in the intent list to the Data Object Broker. These are updates made after the most recent commit.
2.
The Data Object Broker processes the database updates as before, writing them to the redolog, updating the resident page manager buffers, and so on.
3.
Implications for Backup and Recovery
 
You must ensure that you monitor the frequency of checkpoints incurred when new batch processes are added to your TIBCO Object Service Broker system. If the process causes a large number of pages to be updated, the resident page manager buffers fill quickly causing a significant increase in checkpoint requests. Both the redolog and journals must be large enough to accommodate the increased activity. If a new batch process causes a sharp increase in checkpoints, examine the application to see if updates can be clustered together to reduce the number of data pages that require updating.
You must ensure that the merge process completes before the redolog or resident page manager buffers fill up. Otherwise, the system quiesces or abends.

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