A transaction is an interface to manage database operations. All operations to modify data in a transaction must succeed before the server will accept the changes. These operations include methods that set attribute values, standard SQL calls (such as INSERT, UPDATE and DELETE), or more specialized RPC-like calls such as calling Java stored procedures or PL/SQL packages. A transaction is an atomic unit; the effects of the operations in a transaction can be either all committed (saved to the database) or all rolled back (undone).
For example, when a client using a banking service transfers money from a savings account to a checking account, the transaction consists of three separate operations: decrement the savings account, increment the checking account, and record the transaction in a transaction journal. If all three operations are performed to maintain the accounts in proper balance, the transaction is committed and the effects of the operations applied to the database. But, if something (such as insufficient funds, invalid account number, or a hardware failure) prevents any of the operations from completing, the entire transaction must be rolled back so that the balance of all accounts is correct.
Transactions also provide multi-user consistency to a shared store of data. When a client changes data, locks ensure that other clients don't make other changes until the first client is finished. When a transaction is committed or rolled back, the locks are released. This is a "pessimistic" locking mode, which the Business Components for Java framework assumes by default.
Business Component Application Modules provide default transaction and concurrency support. No coding is required unless you want to customize the default behavior.
When programming with Business Components for Java, the principles of transaction management are the same from the middle tier as from a client:
Create an Application Module that connects to the database and establishes a context for the transaction.
Execute a query.
Manipulate the result set (set attributes, validate values).
Commit changes to the database (making the new data available to other Application Modules) or roll them back, as appropriate.
The Business Component for Java framework uses a batch-oriented (as opposed to a change-oriented) approach to synchronize changes in any cached state with the database state. This approach provides the following benefits:
Changes are buffered in an in-memory cache.
Changes in the cache are synchronized with the database using a series of database manipulation operations. This series of operations is typically referred to as posting. (In Business Components for Java, posting is performed in the commit cycle; or by specifically calling postChanges() on the Transaction interface.)
Validations occur on some combination of each state change made and just prior to posting because individual changes may have left the cache in an invalid database state.
Use one of the following constants to represent the locking mode:
ApplicationModule.LOCK_NONE
ApplicationModule.LOCK_OPTIMISTIC
ApplicationModule.LOCK_PESSIMISTIC (default)