How You Can Manage Multiple Sessions and Transactions
Using the commit statement to break a single long transaction into separate, shorter transactions is an important method for increasing concurrent user access to data. Another way to increase concurrency is to open separate database sessions for concurrent frames in an application. For more information about using multiple sessions, see
How Programming for Multiple Sessions Works (see
How Programming for Multiple Sessions Works).
In OpenROAD, transactions can span event blocks and frames but not database sessions. For example, assume a user begins a long transaction on a table in one frame and then needs to open a second frame to perform an update on a different table. The transaction in the first frame remains open while the user performs the update in the second frame.
If an application has multiple database sessions, each session has a separate transaction. Transactions in different database sessions can be open simultaneously.
Transactions continue across event blocks and frames until an explicit commit or rollback statement is issued in the same session in which the transaction was opened, or until the application is terminated.
For example, assume that an application has a frame used to update purchase orders while the data entry clerk is talking to the customer on the telephone. All line items are locked for the duration of the telephone call. This frame also lets the clerk update information about the customer, such as changing a telephone extension or contact.
If the frame opens two database sessions, one to update purchase order information and the other to update customer information, it is not necessary for the frame to hold locks on the customer record while the purchase order is updated.
Any database work performed after the frame switches to the second session either begins a new transaction associated with the second session or participates in an on-going transaction associated with that session. The transaction begun in the first session is still open, but there is no activity associated with it until the frame returns to that session.
Assume further that the frame calls another frame while the first frame is working in the second session. The work performed in the called frame is part of the transaction associated with the second session. If the called frame issues a commit or rollback statement, all the work of the transaction is committed or rolled back, respectively, including the transaction work that originated in the calling frame.
To close either transaction, either the main frame or the called frame must issue a commit or rollback statement while working in the session associated with the transaction. If the application is terminated, OpenROAD automatically commits both transactions.