Question:
How are transactions handled in OPO?
Answer:
Transactions are the core of multi-user data processing integrity. A transaction defines an all-or-none unit of work. The classic example of a transaction is the transfer of money from one account to another. You want to make sure that the amount credited to one account is debited from the other account. If one of these actions does not take place, there will be a discrepancy in the overall amount of money in the accounts, which will lead to acute unhappiness on the part of either the customer or the financial institution.
A transaction that includes both of these actions will let the database handle the management of these actions and prevent a loss of data integrity. The transaction is either committed, which causes the results of both actions to be added to the database, or rolled back, which does not add either of the results to the database.
Oracle Power Objects implements transactions with the session object. All actions that occur through a particular session are handled together through the CommitWork() or RollbackWork() methods of the session. The session object’s IsWorkPending property is set to indicate whether there are any outstanding actions associated with the session object.
Power Objects also provides form level methods, CommitForm() or RollbackForm(), that will trigger the related session method for all sessions associated with containers on the form. If you have an MastSes and an DetSes session associated with the form and a repeater object on the form, the CommitForm() method for the form will trigger the CommitWork() method for both of the sessions.
Power Objects automatically tracks the status of the transactions on a form with the push buttons in the default toolbar. As soon as there is work pending for any session associated with the form, the Commit and Rollback push buttons in the default toolbar are enabled. If there is work pending in the form, Power Objects will not allow you to close the form without first committing or rolling back the changed data.
There are several implications you should be aware of when dealing with transactions. Data changed during a transaction is made available to other users of the database when the transaction ends.
All databases use locks to protect the integrity of data during transactions. Ending a transaction automatically releases any locks being held by the transaction. Since locks can reduce the overall throughput of a database, frequent commits can improve overall database performance.
Database actions for more than one form may be associated with a single session, and commits and roll backs affect all actions associated with a session, so you must be careful that any transaction-ending actions do not adversely affect other data actions. You may want to use more than one session to the same database to avoid potential problems.
Finally, ending a transaction destroys the connection for the transaction. If you have set the RowFetchMode property of a bound container to “Fetch As Needed” or “Fetch Count First” and have not retrieved all the data in the result set, ending a transaction will end the retrieval of data, which may lead to inconsistencies in the client application.
