ACID Transactions

1. ACID Transactions • To understand how transactions work, we will revisit the TravelAgent EJB, the stateful session bean developed in Lecture 11 that encapsulates the process of making a cruise reservation for a customer. The TravelAgent EJB's bookPassage( ) method looks like this: public TicketDO bookPassage(CreditCardDO card, double price) throws IncompleteConversationalState { if (customer == null || cruise == null || cabin == null) { throw new IncompleteConversationalState( ); } try { Reservation reservation = new Reservation( customer, cruise, cabin, price); entityManager.persist(reservation); this.processPayment.byCredit(customer, card, price); TicketDO ticket = new TicketDO(customer,cruise,cabin,price); return ticket; } catch(Exception e) { throw new EJBException(e); } }

2. ACID Transactions • In business, a transaction usually involves an exchange between two parties. • When you purchase an ice cream cone, you exchange money for food; when you work for a company, you exchange skill and time for money (which you use to buy more ice cream). • When you are involved in these exchanges, you monitor the outcome to ensure that you aren't "ripped off." If you give the ice cream vendor a $20 bill, you don't want him to drive off without giving you your change; likewise, you want to make sure that your paycheck reflects all the hours that you worked. • By monitoring these commercial exchanges, you are attempting to ensure the reliability of the transactions; you are making sure that each transaction meets everyone's expectations.

3. ACID Transactions • In business software, a transaction embodies the concept of a commercial exchange. A business system transaction (transaction for short) is the execution of a unit-of-work that accesses one or more shared resources, usually databases. • A unit-of-work is a set of activities that relate to each other and must be completed together. • The reservation process is a unit-of-work made up of several activities: recording a reservation, debiting a credit card, and generating a ticket. • The object of a transaction is to execute a unit-of-work that results in a reliable exchange. Here are some types of business systems that employ transactions:

4. ACID Transactions ATM • The ATM (automatic teller machine) you use to deposit, withdraw, and transfer funds executes these units-of-work as transactions. Online book order • You've probably purchased many of your Java books—maybe even this book - from an online bookseller. This type of purchase is also a unit-of-work that takes place as a transaction. Medical system • In a medical system, important data - some of it critical - is recorded about patients every day, including information about clinical visits, medical procedures, prescriptions, and drug allergies. The doctor prescribes the drug, then the system checks for allergies, contraindications, and appropriate dosages.

5. ACID Transactions • To give you an idea of the accuracy required by transactions, think about what would happen if a transactional system suffered from seemingly infrequent errors. • The transactions handled by ATMs are simple but numerous, providing us with a great example of why transactions must be error-proof. • Let's say that a bank has 100 ATMs in a metropolitan area, and each ATM processes 300 transactions (deposits, withdrawals, and transfers) a day, for a total of 30,000 transactions per day. If each transaction involves the deposit, withdrawal, or transfer of an average of $100, then about $3 million will move through the ATM system per day. In the course of a year, that's a little more than $1 billion: 365 days x 100 ATMs x 300 transactions x $100 = $1,095,000,000

6. ACID Transactions • How well do the ATMs have to perform to be considered reliable? • For the sake of argument, let's say that ATMs execute transactions correctly 99.99% of the time. This seems to be more than adequate: after all, only one out of every 10,000 transactions executes incorrectly. But if you do the math, that could result in more than $100,000 in errors over the course of a year! $1,095,000,000 x .01% = $109,500 • For this reason, experts have identified four characteristics of a transaction that must be met for a system to be considered safe. Transactions must be atomic, consistent, isolated, and durable (ACID)—the four horsemen of transaction services: Atomic • An atomic transaction must execute completely or not at all.

7. ACID Transactions Consistent • Consistency refers to the integrity of the underlying data store. It must be enforced by both the transactional system and the application developer. • The transactional system fulfills this obligation by ensuring that a transaction is atomic, isolated, and durable. • The application developer must ensure that the database has appropriate constraints (primary keys, referential integrity, and so forth) and that the unit-of-work - the business logic - doesn't result in inconsistent data.

8. ACID Transactions Isolated • Isolation means that a transaction must be allowed to execute without interference from other processes or transactions. In other words, the data that a transaction accesses cannot be affected by any other part of the system until the transaction or unit-of-work is completed. Durable • Durability means that all the data changes made during the course of a transaction must be written to some type of physical storage before the transaction is successfully completed. This ensures that the changes are not lost if the system crashes. • To get a better idea of what these principles mean, we will examine the TravelAgent EJB in terms of the four ACID properties.

9. Is the TravelAgent EJB Atomic? • So the only way bookPassage( ) can be completed is if all the critical tasks execute successfully. If something goes wrong, the entire process must be aborted. • Aborting a transaction requires more than simply not finishing the tasks; in addition, all the tasks that did execute within the transaction must be undone. • If, for example, the creation of the Reservation entity and ProcessPayment.byCredit( ) method succeeded, but the creation of the TicketDO object failed (throwing an exception from the constructor) the reservation and payment records must not be added to the database.

10. Is the TravelAgent EJB Consistent? • If, for example, the application developer fails to include the credit card charge operation in the bookPassage( ) method, the customer will be issued a ticket but will never be charged. The data will be inconsistent with the expectation of the business - a customer should be charged for passage. • In addition, the database must be set up to enforce integrity constraints. For example, it should not be possible for a record to be added to the RESERVATION table unless the CABIN_ID, CRUISE_ID , and CUSTOMER_ID foreign keys map to corresponding records in the CABIN, CRUISE, and CUSTOMER tables, respectively. If a CUSTOMER_ID that does not map to a CUSTOMER record is used, referential integrity should cause the database to throw an error message.

11. Is the TravelAgent EJB Isolated? • If you are familiar with the concept of thread synchronization in Java or row-locking schemes in relational databases, isolation will be a familiar concept. • To be isolated, a transaction must protect the data it is accessing from other transactions. • Imagine the problems that would arise if separate transactions were allowed to change any entity bean at any time - transactions would walk all over each other. • Several customers could easily book the same cabin because their travel agents happened to make their reservations at the same time.

12. Is the TravelAgent EJB Durable? • To be durable, the bookPassage( ) method must write all changes and new data to a permanent data store before it can be considered successful. While this may seem like a no-brainer, often it is not what happens in real life. • In the name of efficiency, changes are often maintained in memory for long periods of time before being saved on a disk drive. • The idea is to reduce disk accesses - which slow systems down - and only periodically write the cumulative effect of data changes. While this approach is great for performance, it is also dangerous because data can be lost when the system goes down and memory is wiped out. • In the TravelAgent EJB, this means that the new RESERVATION and PAYMENT records inserted are made persistent before the transaction can complete successfully.

13. Declarative Transaction Management • One of the primary advantages of Enterprise JavaBeans is that it allows for declarative transaction management. Without this feature, transactions must be controlled using explicit transaction demarcation, which involves the use of fairly complex APIs like the OMG's Object Transaction Service (OTS) or its Java implementation, the Java Transaction Service (JTS). • With declarative transaction management, the transactional behavior of EJBs can be controlled using the @javax.ejb.TransactionAttribute annotation or the EJB deployment descriptor, both of which can set transaction attributes for individual enterprise bean methods. • This means that the transactional behavior of an EJB can be changed without changing the EJB's business logic by simply annotating the method in a different way or modifying XML.

14. Transaction Scope • Transaction scope is a crucial concept for understanding transactions. In this context, transaction scope refers to those EJBs—both session and entity—that are participating in a particular transaction. In the bookPassage( ) method of the TravelAgent EJB, all the EJBs involved are part of the same transaction scope. • The scope of the transaction starts when a client invokes the TravelAgent EJB's bookPassage( ) method. Once the transaction scope has started, it is propagated to both the entity manager service that is responsible for creating reservations and the ProcessPayment EJB. • A transaction can end if an exception is thrown while the bookPassage( ) method is executing. The exception can be thrown from one of the other EJBs or from the bookPassage( ) method itself. An exception may or may not cause a rollback, depending on its type.

15. Transaction Attributes • As an application developer, you don't normally need to control transactions explicitly when using an EJB server. EJB servers can manage transactions implicitly, based on the transaction attributes established at deployment time. • When an EJB is deployed, you can set its runtime transaction attribute in the @javax.ejb.TransactionAttribute annotation or deployment descriptor to one of several values: • NotSupported • Supports • Required • RequiresNew • Mandatory • Never • You can set a transaction attribute for the entire EJB (in which case it applies to all methods) or you can set different transaction attributes for individual methods.

16. Using the @TransactionAttribute annotation • The @javax.ejb.TransactionAttribute annotation can be used to apply transaction attributes to your EJB's bean class. The attribute is defined using the javax.ejb.TransactionAttributeType Java enum: public enum TransactionAttributeType { MANDATORY, REQUIRED, REQUIRES_NEW, SUPPORTS, NOT_SUPPORTED, NEVER } @Target({METHOD, TYPE}) public @interface TransactionAttribute { TransactionAttributeType value( ) default TransactionAttributeType.REQUIRED; }

17. Using the @TransactionAttribute annotation • The @TransactionAttribute can be applied per method, or you can use it on the bean class to define the default transaction attribute for the entire bean class: import static TransactionAttributeType.*; @Stateless @TransactionAttribute(NOT_SUPPORTED) public class TravelAgentBean implements TravelAgentRemote { public void setCustomer(Customer cust) {...} @TransactionAttribute(REQUIRED) public TicketDO bookPassage(CreditCardDO card, double price) { ... } }

18. Setting a transaction attribute within XML • In the XML deployment descriptor, a <container-transaction> element specifies the transaction attributes for the EJBs described in the deployment descriptor: <ejb-jar xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd" version=3.0> <assembly-descriptor> <container-transaction> <method> <ejb-name>TravelAgentEJB</ejb-name> <method-name> * </method-name> </method> <trans-attribute>NotSupported</trans-attribute> </container-transaction> <container-transaction> <method> <ejb-name>TravelAgentEJB</ejb-name> <method-name>bookPassage</method-name> </method> <trans-attribute>Required</trans-attribute> </container-transaction> </assembly-descriptor> </ejb-jar>

19. Transaction attributes defined • The definitions of the transaction attributes listed earlier are presented in the following slides.

20. NotSupported • Invoking a method on an EJB with this transaction attribute suspends the transaction until the method is completed. • This means that the transaction scope is not propagated to the NotSupported EJB or to any of the EJBs it calls. Once the method on the NotSupported EJB is done, the original transaction resumes its execution. • Figure below shows that a NotSupported EJB does not propagate the client transaction when one of its methods is invoked.

21. Supports • This attribute means that the enterprise bean method will be included in the transaction scope if it is invoked within a transaction. In other words, if the EJB or client that invokes the Supports EJB is part of a transaction scope, the Supports EJB and all EJBs accessed by it become part of the original transaction. • Figure a below shows the Supports EJB being invoked by a transactional client and propagating the transaction. Figure b shows the Supports EJB being invoked by a nontransactional client.

22. Required • This attribute means that the enterprise bean method must be invoked within the scope of a transaction. If the calling client or EJB is part of a transaction, the Required EJB is automatically included in its transaction scope. If, however, the calling client or EJB is not involved in a transaction, the Required EJB starts its own new transaction. • Figure a below shows the Required EJB being invoked by a transactional client and propagating the transaction. Figure b shows the Required EJB being invoked by a nontransactional client, which causes it to start its own transaction.

23. RequiresNew • This attribute means that a new transaction is always started. Regardless of whether the calling client or EJB is part of a transaction, a method with the RequiresNew attribute begins a new transaction when invoked. If the calling client is already involved in a transaction, that transaction is suspended until the RequiresNew EJB's method call returns. • Figure a below shows the RequiresNew EJB being invoked by a transactional client. The client's transaction is suspended while the EJB executes under its own transaction. Figure b shows the RequiresNew EJB being invoked by a nontransactional client.

24. Mandatory • This attribute means that the enterprise bean method must always be made part of the transaction scope of the calling client. The EJB may not start its own transaction; the transaction must be propagated from the client. If the calling client is not part of a transaction, the invocation will fail, throwing a javax.ejb.EJBTransactionRequiredException . • Figure a shows the Mandatory EJB invoked by a transactional client and propagating the transaction. Figure b shows the Mandatory EJB invoked by a nontransactional client.

25. Never • This attribute means that the enterprise bean method must not be invoked within the scope of a transaction. If the calling client or EJB is part of a transaction, the Never EJB will throw an EJBException. However, if the calling client or EJB is not involved in a transaction, the Never EJB will execute normally without a transaction. • Figure a below shows the Never EJB being invoked by a nontransactional client. Figure b shows the Never EJB being invoked by a transactional client.

26. EJB 3.0 persistence and transaction attributes • The EJB specification strongly advises that EntityManagers be accessed within the scope of a JTA transaction. • So, if you are wrapping access to your persistent entities with EJBs, use only the Required, RequiresNew, and Mandatory transaction attributes. • This restriction ensures that all database access occurs in the context of a transaction, which is important when the container is automatically managing persistence. • There are valid exceptions to this rule when using extended persistence contexts with stateful session beans, but we'll talk about these exceptions later.

27. Message-driven beans and transaction attributes • Message-driven beans may declare only the NotSupported or Required transaction attribute. The other transaction attributes don't make sense in message-driven beans because they apply to client-initiated transactions. • The Supports, RequiresNew, Mandatory, and Never attributes are all relative to the transaction context of the client. For example, the Mandatory attribute requires the client to have a transaction in progress before calling the enterprise bean. This is meaningless for a message-driven bean, which is decoupled from the client. • The NotSupported transaction attribute indicates that the message will be processed without a transaction. The Required transaction attribute indicates that the message will be processed with a container-initiated transaction.

28. EJB endpoints and transaction attributes • The Mandatory transaction attribute cannot be used with EJB endpoints because an EJB endpoint does not propagate a client transaction. • This may change when web service transactions become standardized, but for now, using Mandatory with an EJB endpoint method is prohibited.

29. Transaction Propagation • To illustrate the impact of transaction attributes, we'll look once again at the bookPassage( ) method of the TravelAgent EJB. In order for bookPassage( ) to execute as a successful transaction, both the creation of the Reservation entity and the charge to the customer must be successful. • We could have specified the Required transaction attribute as the default for all the EJBs involved because that attribute enforces our desired policy that all EJBs must execute within a transaction and thus ensures data consistency. • As a transaction monitor, an EJB server watches each method call in the transaction. If any of the updates fail, all the updates to all the EJBs and entities will be reversed or rolled back. For example, if the Reservation entity cannot be created by the EntityManager, the charge made by the ProcessPayment EJB is rolled back. • Transactions make updates an all-or-nothing proposition. This ensures that the unit-of-work, like the bookPassage( ) method, executes as intended, and it prevents inconsistent data from being written to databases.

30. Transaction Propagation • Let's assume that the TravelAgent EJB is created and used on a client as follows: TravelAgent agent = (TravelAgent)jndi.lookoup("TravelAgent"); agent.setCabinID(cabin_id); agent.setCruiseID(cruise_id); try { agent.bookPassage(card,price); } catch(Exception e) { System.out.println("Transaction failed!"); } • Furthermore, let's assume that the bookPassage( ) method has been given the transaction attribute RequiresNew. In this case, the client that invokes the bookPassage( ) method is not itself part of a transaction. When bookPassage( ) is invoked on the TravelAgent EJB, a new transaction is created, as dictated by the RequiresNew attribute. • If a system exception or a rollback application exception is thrown by the bookPassage( ) method, the transaction is automatically rolled back. We talk more about exceptions later.

31. Transaction Propagation • Figure below illustrates the propagation and management of the TravelAgent EJB's transactional context.

32. Transaction Propagation • In addition to managing transactions in its own environment, an EJB server can coordinate with other transactional systems. If, for example, the ProcessPayment EJB actually came from a different application server than the TravelAgent EJB, the two application servers would cooperate to manage the transaction as one unit-of-work. • This is called a distributed transaction. A distributed transaction requires what is called a two-phase commit (2-PC or TPC). A 2-PC allows transactions to be managed across different servers and resources (e.g., databases and JMS providers).

33. Transactions and persistence context propagation • There are some transaction propagation rules to consider when invoking on multiple different EJBs within the same transaction that use entity managers. Here is a more detailed list of persistence context-propagation rules: • When a transaction-scoped entity manager is invoked outside the scope of a transaction, it creates a persistence context for the duration of that method call. After the method call completes, any managed objects produced by the call are immediately detached. Lecture 5 gives a detailed list of methods that are allowed to be invoked outside of a transaction. • If a transaction-scoped entity manager is invoked from within a transaction, a new persistence context is created if there isn't one already and associated with that transaction.

34. Transactions and persistence context propagation • If an entity manager is invoked upon and a persistence context is already associated with the transaction, use that persistence context. The persistence context is propagated between EJB invocations in the same transaction. This means that if an EJB interacts with an injected entity manager within a transaction and then invokes on another EJB within that same transaction, that EJB call will use the same enlisted persistence context. • If an EJB with a transaction-scoped persistence context invokes on a stateful session bean that uses an extended persistence context, an error is thrown.

35. Transactions and persistence context propagation • If a stateful session bean with an extended persistence context calls another EJB that has injected a transaction-scoped persistence context, the extended persistence context is propagated. • If an EJB calls another EJB with a different transaction scope, the persistence context, whether it is extended or not, is not propagated. • If a stateful session bean with an extended persistence context calls another noninjected stateful session bean with an extended persistence context, an error is thrown.

36. Isolation and Database Locking • Transaction isolation (the "I" in ACID) is a critical part of any transactional system. • This section explains isolation conditions, database locking, and transaction isolation levels. These concepts are important when deploying any transactional system.

37. Dirty, Repeatable, and Phantom Reads • Transaction isolation is defined in terms of isolation conditions called dirty reads, repeatable reads, and phantom reads. • These conditions describe what can happen when two or more transactions operate on the same data. • To illustrate these conditions, let's think about two separate client applications using their own instances of the TravelAgent EJB to access the same data - specifically, a cabin record with a primary key of 99. • These examples revolve around the RESERVATION table, which is accessed by both the bookPassage( ) method (through the Reservation entity) discussed at the beginning of this lecture and in Lecture 11, and a new listAvailableCabins( ) method that uses EJB QL to query cabin lists:

38. Dirty, Repeatable, and Phantom Reads public List listAvailableCabins(int bedCount) throws IncompleteConversationalState { if (cruise == null) throw new IncompleteConversationalState( ); Query query = entityManager.createQuery("SELECT name FROM Cabin c WHERE c.ship = :ship AND c.bedCount = :beds AND NOT ANY (SELECT cabin from Reservation res WHERE res.cruise = :cruise"); query.setParameter("ship", cruise.getShip( )); query.setParameter("beds", bedCount); query.setParameter("cruise", cruise); return query.getResultList( ); } • For this example, assume that both methods have a transaction attribute of Required.

39. Dirty reads • A dirty read occurs when a transaction reads uncommitted changes made by a previous transaction. If the first transaction is rolled back, the data read by the second transaction becomes invalid because the rollback undoes the changes. The second transaction will not be aware that the data it has read has become invalid. Here's a scenario showing how a dirty read can occur (illustrated in Figure below):

40. Dirty reads • Time 10:00:00: Client 1 executes the TravelAgent.bookPassage( ) method. Along with the Customer and Cruise entities, Client 1 had previously chosen Cabin 99 to be included in the reservation. • Time 10:00:01: Client 1's TravelAgent EJB creates a Reservation entity within the bookPassage( ) method. The EntityManager inserts a record into the RESERVATION table, which reserves Cabin 99. • Time 10:00:02: Client 2 executes TravelAgent.listAvailableCabins( ). Client 1 has reserved Cabin 99, so it is not in the list of available cabins that is returned from this method. • Time 10:00:03: Client 1's TravelAgent EJB executes the ProcessPayment.byCredit( ) method within the bookPassage( ) method. The byCredit( ) method throws an exception because the expiration date on the credit card has passed. • Time 10:00:04: the exception thrown by the ProcessPayment EJB causes the entire bookPassage( ) transaction to be rolled back. As a result, the record inserted into the RESERVATION table when the Reservation EJB was created is not made durable (i.e., it is removed). Cabin 99 is now available.

41. Repeatable reads • A repeatable read occurs when the data read is guaranteed to look the same if read again during the same transaction. Repeatable reads are guaranteed in one of two ways: either the data read is locked against changes, or it is a snapshot that doesn't reflect changes. • If the data is locked, it cannot be changed by any other transaction until the current transaction ends. If the data is a snapshot, other transactions can change the data, but these changes will not be seen by this transaction if the read is repeated. Here's an example of a repeatable read (illustrated Figure below):

42. Repeatable reads • Time 10:00:00: Client 1 begins an explicit javax.transaction.UserTransaction. • Time 10:00:01: Client 1 executes TravelAgent.listAvailableCabins(2), asking for a list of available cabins that have two beds. Cabin 99 is in the list of available cabins. • Time 10:00:02: Client 2 is working with an interface that manages cabins. Client 2 attempts to change the bed count on Cabin 99 from 2 to 3. • Time 10:00:03: Client 1 re-executes TravelAgent.listAvailableCabins(2). Cabin 99 is still in the list of available cabins. • A nonrepeatable read occurs when the data retrieved in a subsequent read within the same transaction can return different results. In other words, the subsequent read can see the changes made by other transactions.

43. Phantom reads • A phantom read occurs when new records added to the database are detectable by transactions that started prior to the insert. Queries will include records added by other transactions after their transaction has started. Here's a scenario that includes a phantom read (illustrated in Figure below):

44. Phantom reads • Time 10:00:00: Client 1 begins an explicit javax.transaction.UserTransaction. • Time 10:00:01: Client 1 executes TravelAgent.listAvailableCabins(2), asking for a list of available cabins that have two beds. Cabin 99 is in the list of available cabins. • Time 10:00:02: Client 2 executes bookPassage( ) and creates a reservation. The reservation inserts a new record into the RESERVATION table, reserving Cabin 99. • Time 10:00:03: Client 1 reexecutes TravelAgent.listAvailableCabins(2). Cabin 99 is no longer in the list of available cabins.

45. Database Locks • Databases, especially relational databases, normally use several different locking techniques. • The most common are read locks, write locks, and exclusive write locks. (I've taken the liberty of adding "snapshots" to this list of techniques, although this isn't a formal term.) These locking mechanisms control how transactions access data concurrently. • Locking mechanisms impact the read conditions described in the previous section. • Database vendors implement these locks differently, so you should understand how your database addresses these locking mechanisms to best predict how the isolation levels described in this section will work.

46. Database Locks • The four types of locks are: Read locks • Read locks prevent other transactions from changing data read during a transaction until the transaction ends, thus preventing nonrepeatable reads. Other transactions can read the data but not write to it. The current transaction is also prohibited from making changes. Whether a read lock locks only the records read, a block of records, or a whole table depends on the database being used. Write locks • Write locks are used for updates. A write lock prevents other transactions from changing the data until the current transaction is complete but allows dirty reads by other transactions and by the current transaction itself. In other words, the transaction can read its own uncommitted changes.

47. Database Locks Exclusive write locks • Exclusive write locks are used for updates. An exclusive write lock prevents other transactions from reading or changing the data until the current transaction is complete. It also prevents dirty reads by other transactions. Some databases do not allow transactions to read their own data while it is exclusively locked. Snapshots • A snapshot is a frozen view of the data that is taken when a transaction begins. Some databases get around locking by providing every transaction with its own snapshot. Snapshots can prevent dirty reads, nonrepeatable reads, and phantom reads. They can be problematic because the data is not real-time data; it is old the instant the snapshot is taken.

48. Transaction Isolation Levels • Transaction isolation is defined in terms of the isolation conditions (dirty reads, repeatable reads, and phantom reads). Isolation levels are commonly used in database systems to describe how locking is applied to data within a transaction. The following terms are used to discuss isolation levels: Read Uncommitted • The transaction can read uncommitted data (i.e., data changed by a different transaction that is still in progress). Dirty reads, nonrepeatable reads, and phantom reads can occur. Bean methods with this isolation level can read uncommitted changes. Read Committed • The transaction cannot read uncommitted data; data that is being changed by a different transaction cannot be read. Dirty reads are prevented; nonrepeatable reads and phantom reads can occur. Bean methods with this isolation level cannot read uncommitted data.

49. Transaction Isolation Levels Repeatable Read • The transaction cannot change data that is being read by a different transaction. Dirty reads and nonrepeatable reads are prevented; phantom reads can occur. Bean methods with this isolation level have the same restrictions as those in the Read Committed level and can execute only repeatable reads. Serializable • The transaction has exclusive read and update privileges; different transactions can neither read nor write to the same data. Dirty reads, nonrepeatable reads, and phantom reads are prevented. This isolation level is the most restrictive. • The exact behavior of these isolation levels depends largely on the locking mechanism used by the underlying database or resource. How the isolation levels work depends in large part on how your database supports them. • In EJB, the deployer sets transaction isolation levels in a vendor-specific way if the container manages the transaction. The EJB developer sets the transaction isolation level if the enterprise bean manages its own transactions.

50. Controlling isolation levels • Different EJB servers allow different levels of granularity for isolation levels; some servers defer this responsibility to the database. • Most EJB servers and EntityManager implementations control the isolation level through the resource access API (e.g., JDBC and JMS) and may allow different resources to have different isolation levels. • However, they will generally require a consistent isolation level for access to the same resource within a single transaction. Consult your vendor's documentation to find out the level of control your server offers. • Bean-managed transactions in session beans and message-driven beans, however, allow you to specify the transaction isolation level using the database's API. The JDBC API, for instance, provides a mechanism for specifying the isolation level of the database connection. For example: DataSource source = (javax.sql.DataSource) jndiCntxt.lookup("java:comp/env/jdbc/titanDB"); Connection con = source.getConnection( ); con.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE);