Transactions
For the most part, Enterprise Objects Framework handles transactions for you. You rarely (if ever) need to explicitly start or end a transaction yourself-it generally happens as the by-product of another operation, such as a fetch or save. However, understanding how transactions are handled in the Framework can help you to make the right decisions for your application.
The way that each of these modes affects transactions is described in the following sections.
Transactions and Optimistic Locking
If you're using optimistic locking (the default) and you're just fetching objects, Enterprise Objects Framework never explicitly starts or stops transactions. Instead, when a SELECT is performed on a database row, opening (and subsequently closing) a transaction is typically handled by the database server itself, implicitly. Ultimately, it is the responsibility of the adaptor for each database server to ensure that the right thing happens.
Consequently, using pessimistic locking is very expensive. It's not suitable for applications that have user interaction since large portions of your database could be locked down for indeterminate periods of time. A good alternative to pessimistic locking is using on-demand locking to lock individual objects.
Table of Contents Next Section