1. JPA Transactions eric.gerlofsma@hu.nl www.ericgerlofsma.nl

2. 1/26/2016www.ericgerlofsma.nl ACID Transactions Atomic - An atomic transaction must execute completely or not at all. Consistent – A consistent transaction doesn’t result in inconsistent data. Isolated – An isolated transaction executes without interference from other processes. Durable – A durable transaction is written to some type of physical storage.

3. 1/26/2016www.ericgerlofsma.nl EJB Transactions Container calls to SessionBeans are automatically part of transaction demarcation. It’s the responsibility of the container to start a transaction and finally commit this transaction or rollback this transaction in case of an system-exception. The container allows for declarative transaction management by annotation, so users can specify there transaction scope.

4. 1/26/2016www.ericgerlofsma.nl System Exceptions System exceptions represent unknown internal errors and include: 1.java.lang.RuntimeException and its subclasses. 2.java.rmi.RemoteException and its subclasses java.lang.Object java.lang.Throwable java.lang.Exception java.io.IOException java.rmi.RemoteException java.lang.RuntimeException javax.ejb.EJBException java.lang.NullPointerException java.lang.IndexOutOfBoundsException The container handles system exceptions automatically and will always do the following: 1.Roll back the transaction 2.Log the exception to alert the system administrator 3.Discard the EJB instance System exceptions can be turned into application exceptions using the @javax.ejb.ApplicationException annotation.

5. 1/26/2016www.ericgerlofsma.nl Application Exceptions System exceptions are exceptions that are part of your business logic. They denote a strongly typed definition of a specific business problem or failure but do not necessary abort or roll back the business process. The @javax.ejb.ApplicationException annotation may be used to force an application exception to roll back the transaction automatically. @Target( { TYPE } ) @Retention(RUNTIME) public @interface ApplicationException { boolean rollback() default false; }

6. 1/26/2016www.ericgerlofsma.nl TransactionAttribute Annotation @Target( { METHOD, TYPE } ) public @interface TransactionAttribute { TransactionAttributeType value() default TransactionAttributeType.REQUIRED; } public enum TransactionAttributeType { MANDATORY, REQUIRED, REQUIRES_NEW, SUPPORTS, NOT-SUPPORTED, NEVER }

7. 1/26/2016www.ericgerlofsma.nl Transaction: 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 will fail, throwing a javax.ejb.EJBTransactionRequiredException. - Bill Burke - Client(EJB or app) EJBB Client(EJB or app) EJB

8. 1/26/2016www.ericgerlofsma.nl Transaction: 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. The new transaction’s scope covers only the Required EJB and all other EJBs accessed by it. Once the method invoked on the Required EJB is done, the new transaction’s scope ends. This is the default ! - Bill Burke - Client(EJB or app) EJB Client(EJB or app)) EJB

9. 1/26/2016www.ericgerlofsma.nl Transaction: REQUIRES_NEW 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 calls return. The new transaction’s scope covers only the RequiresNew EJB and all the EJB’s accessed by it. Once the method invoked on the RequiresNew EJB is done, the new transaction scope ends and the original transaction resumes. - Bill Burke - Client(EJB or app) EJB Client(EJB or app)) EJB

10. 1/26/2016www.ericgerlofsma.nl Transactions: 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. However, the Supports EJB doesn’t have to be part of a transaction and can interact with clients and other EJBs that are not included in a transaction scope. - Bill Burke - Client(EJB or app) EJB Client(EJB or app)) EJB

11. 1/26/2016www.ericgerlofsma.nl Transaction: NOT_SUPPORTED 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. - Bill Burke - Client(EJB or app) EJB Client(EJB or app)) EJB

12. 1/26/2016www.ericgerlofsma.nl Transaction: 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 exception. However, if the calling client or EJB is not involved in a transaction, the Never EJB will execute normaly without a transaction. - Bill Burke - Client(EJB or app) EJB Client(EJB or app)) EJB

13. 1/26/2016www.ericgerlofsma.nl Isolation conditions Transaction isolation is defined in terms of 3 isolation conditions: dirty reads - transaction reads uncommitted changes repeatable reads – data is guaranteed to look the same if read again during the same transaction phantom reads – new records are detectable by transactions that started prior to the insert. These conditions describe what can happen when two or more transactions operate on the same data. - Bill Burke -

14. 1/26/2016www.ericgerlofsma.nl Isolation levels Transaction isolation is defined in terms of 4 isolation levels: Read Uncommitted - transaction can read uncommitted data Read Committed - transaction cannot read uncommitted data Repeatable Read - transaction cannot change data that is being read by a different transaction. Serializable - transaction has exclusive read and update privileges. These isolation levels are the same as those defined for JDBC. - Bill Burke - Specifying the isolation level: DataSource source = (javax.sql.DataSource)jndiCntxt.lookup(“java:comp/env/jdbc/titanDB”); Connection con = source.getConnection(); con.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE);

15. 1/26/2016www.ericgerlofsma.nl Database Locking Databases, especially relational databases, normally use several different locking techniques: read locks prevents other transactions from changing data read during a transaction, thus preventing nonrepeatable reads. write locks prevents other transactions from changing data during a transaction, but allow dirty reads. exclusive write locks prevents other transactions from reading or changing data during a transaction snapshots prevents dirty reads, nonrepeatable reads and phantom reads - Bill Burke -

16. 1/26/2016www.ericgerlofsma.nl Optimistic Locking Optimistic locking isn’t locking in the traditional sense. Assume no other transaction is inferring. At commit time, let the database resolve whether the “version-field” has been changed. Is the version changed throw an exception. - Bill Burke - private long version; @Version protected long getVersion() {return version;} protected void setVersion(long newVersion){ version = newVersion }; The annotation results in automatic incrementing the version field after any update of the table-entry!

17. 1/26/2016www.ericgerlofsma.nl Programmatic Locking public interface EntityManager { void lock(Object entity, LockModeType type); } LockModeType.READ - no dirty and nonrepeatable reads can occur LockModeType.WRITE - no dirty and nonrepeatable reads can occur also forces an increment of the @Version property Programmatic locking becomes important when you want to ensure nonrepeatable reads on entity beans that may be read within the transaction but not updated. - Bill Burke -