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
The request for data 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. The Execution Environment requests that a logical shared-lock be placed on the occurrences being accessed.
If the transaction runs with BROWSE=YES, no logical locks are taken.
2.
The Data Object Broker retrieves the required data pages from memory or from the Pagestore and loads it into internal memory (assuming that the page is not already there).
3.
Task B The Transaction Performs an Update
Possible accesses include the following:
During the access, the following occurs:
1.
The Execution Environment sends a lock upgrade request to the Data Object Broker to obtain an exclusive lock on the occurrence that it plans to update.
2.
The data is not yet physically changed and is not changed until a commit is issued. The Execution Environment keeps track of the changes, however, to ensure integrity and consistency are maintained.
Task C An Intermediate Commit Command is Issued
The following occurs after the commit command is issued:
1.
2.
If an updated segment reaches its predefined capacity threshold, that is, it is nearing full capacity, warning messages are sent to the operator console.
3.
The Data Object Broker updates data pages in memory. This ensures that these new database updates are reflected in future accesses to the same data by other transactions.
4.
The Data Object Broker writes the database update request (intent list) to the redolog. This operation guarantees that all committed updates are written to the database.
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 cache, journals, and Pagestore itself.
7.
If the current journal fills up during a checkpoint, the Data Object Broker starts the spin process (refer to Spinning the Journals for details) and switches to another journal.
Task D The Transaction Ends
The following occurs:
1.
Since the ending of a transaction implies a Commit, the Execution Environment passes the intent list to the Data Object Broker. These are the commands issued after the most recent Commit.
2.
3.
Implications for Backup and Recovery
Here are some potential implications of transaction processing on your backup and recovery system.
Frequency of Checkpoints
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.

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