Documentation Archive Developer
Search
PATH  Documentation > WebObjects 4.5 > EOF Developer's Guide

Table of Contents Previous Section

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.

How transactions are handled in the Framework depends on the locking mode you have set. There are three different possibilities:

For a detailed description of these locking modes, see the section "Locking and Update Strategies".

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.

Under optimistic locking, Enterprise Objects Framework explicitly starts a transaction when you perform a save operation. A save operation consists of three basic parts:

Transactions and Pessimistic Locking

 When you use pessimistic locking, Enterprise Objects Framework explicitly starts a transaction as soon as you fetch objects, and every object you fetch is locked. The transaction stays open until you commit it (using the EOEditingContext method saveChanges), or roll it back (using the EOEditingContext method invalidateAllObjects).

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.

Transactions and On-Demand Locking

When you use on-demand locking to get a server lock on an object, Enterprise Objects Framework explicitly opens a transaction and keeps it open as long as you have a lock on the object. The transaction stays open until you commit it (using the EOEditingContext method saveChanges), or roll it back (using the EOEditingContext method invalidateAllObjects).

Table of Contents Next Section