Transactions
Transactions are supposed to be atomic, that is, everything succeeds or everything fails together. However, database engines generally allow many simultaneous connections to be reading and updating data simultaneously. Thus it is very possible for one connection to read or update data that another connection is in the process of reading or updating. Where this simulataneous access is permitted, the following types of error can occur:
EJB containers must support both container managed ACID transactions and bean managed transactions.
Container-managed transactions (CMT) are by default active for calls to session beans. That is, no explicit configuration is needed. This behavior may be declaratively tuned by the bean via annotations and if needed such configuration can later be overridden in the deployment descriptor. Tuning includes switching off transactions for the whole bean or specific methods, or requesting alternative strategies for transaction propagation and starting or joining a transaction. Such strategies mainly deal with what should happen if a transaction is or isn't already in progress at the time the bean is called. The following variations are supported:
| Declarative Transactions Management Types | |
| Type | Explanation |
| MANDATORY | If the client has not started a transaction, an exception is thrown. Otherwise the client's transaction is used. |
| REQUIRED | If the client has started a transaction, it is used. Otherwise a new transaction is started. (this is the default when no explicit type has been specified) |
| REQUIRES_NEW | If the client has started a transaction, it is suspended. A new transaction is always started. |
| SUPPORTS | If the client has started a transaction, it is used. Otherwise, no transaction is used. |
| NOT_SUPPORTED | If the client has started a transaction, it is suspended. No new transaction is started. |
| NEVER | If the client has started a transaction, an exception is thrown. No new transaction is started. |
Alternatively, the bean can also declare via an annotation that it wants to handle transactions programmatically via the JTA API. This mode of operation is called Bean Managed Transactions (BMT), since the bean itself handles the transaction instead of the container.
ACID
| Atomic | It means a transaction must execute all or nothing at all. |
| Consistent | Consistency is a transactional characteristic that must be enforced by both the transactional system and the application developer |
| Isolation | Transaation must be allowed to run itselft without the interference of the other process or transactions. |
| Durable | Durablity means that all the data changes that made by the transaction must be written in some type of physical storage before the transaction is successfully completed. This ensures that transacitons are not lost even if the system crashes. |
Isolation Levels
| Isolation Level | Description |
|---|---|
| TRANSACTION_SERIALIZABLE | Strongest level of isolation. All rows locked for duration of transaction. Can produce deadlocks! (But not if Find for Update set to false.) A transaction ensures that no other transaction can read or write to the data it accesses. Dirty reads, nonrepeatable reads and phantom reads are not possible. |
| TRANSACTION_REPEATABLE_READ | Transaction always reads same data during transaction. Phantom records possible. Default level of isolation set by WebSphere Studio. Usually suitable for all but most critical operations. Once a transaction has read a set of data, repeated reads of the same data return the same values, even if other transactions have subsequently modified the data. Dirty reads and nonrepeatable reads are not possible, but phantom reads are. |
| TRANSACTION_READ_COMMITTED | Can not read uncommitted data by another transaction, but nonrepeatable reads and phantom records possible. A transaction is not allowed to read uncommitted data. Dirty reads are not possible, but nonrepeatable reads and phantom reads are. |
| TRANSACTION_READ_UNCOMMITTED | Can read uncommitted data by another transaction, and nonrepeatable reads and phantom records possible. A transaction may read any data currently on a data page, regardless of whether or not the data has been committed. Dirty reads, nonrepeatable reads, and phantom reads are possible. |
Transactions are supposed to be atomic, that is, everything succeeds or everything fails together. However, database engines generally allow many simultaneous connections to be reading and updating data simultaneously. Thus it is very possible for one connection to read or update data that another connection is in the process of reading or updating. Where this simulataneous access is permitted, the following types of error can occur:
| Error | Description |
|---|---|
| Dirty reads | A transaction reads data written by another transaction that has not been committed yet. Because this data is uncommitted, a transaction failure would roll back these read changes. Occurs when one transaction (T2) reads data that has been modified by previously started transaction (T1), but not committed What happens if the T1 rolls back? T1 has incorrect data, thus "dirty read". |
| Nonrepeatable reads | A transaction rereads data it has previously read and finds that data has been modified by another committed transaction in the meantime. Occurs when one transaction (T1) reads same data twice, while another transaction (T2) modifies the data between the two reads by T1. T1 gets different value between the first and the second read, thus "nonrepeatable read". |
| Phantom reads | A transaction reexecutes a query returning a set of rows that satisfy a search condition and finds that the set of rows satisfying the condition has changed due to another committed transaction in the meantime. Occurs when one transaction begins reading data and another inserts to or deletes data from the table being read. |
Isolation levels in EJB transactions
A database engine will provide isolation of transactions, that is, transactions are prevented from interacting with one another and giving rise to the error described above. However, complete isolation of transactions, although offering the greatest assurance of data integrity, is potentially a performance bottleneck and may not be required. An EJB that is starting a transaction may therefore, in some circumstances, request a particular level of isolation. The levels that are available are shown below.
Isolation levels in EJB transactions
| Isolation level | Dirty reads may occur | Nonrepeatable reads may occur | Phantom reads may occur |
|---|---|---|---|
| TRANSACTION_READ_UNCOMMITTED (no isolation) | Yes | Yes | Yes |
| TRANSACTION_READ_COMMITTED (partial isolation) | No | Yes | Yes |
| TRANSACTION_REPEATABLE_READ (partial isolation) | No | No | Yes |
| TRANSACTION_SERIALIZABLE (full isolation) | No | No | No |
With Entity EJBs that use container-managed persistence (CMP), the developer has NO control over the isolation level provided for transactions. This is because the synchronization of the data with the persistent store is handled entirely by the container. In all other cases, the EJB may set the isolation level.
| Possible values | JDBC isolation level | DB2 isolation level |
|---|---|---|
| 8 | TRANSACTION_SERIALIZABLE | Repeatable Read (RR) |
4 | TRANSACTION_REPEATABLE_READ | Read Stability (RS) |
| 2 | TRANSACTION_READ_COMMITTED | Cursor Stability (CS) |
| 1 | TRANSACTION_READ_UNCOMMITTED | Uncommitted Read (UR) |
Default Isolation Levels-
- Weblogic Server- 2
- DB2- 4
These values can be configured in server specific ejb-jar.xml file like below.
<transaction-isolation><isolation-level>...</isolation-level><method><description>...</description><ejb-name>...</ejb-name><method-intf>...</method-intf><method-name>...</method-name><method-params>...</method-params></method></transaction-isolation>
