Is the BlackjackEJB Durable in Java

Creator QR-Code in Java Is the BlackjackEJB Durable

To be durable, a business method must write all changes and new data to a permanent data store before it can be considered successful. This may seem like a no-brainer, but often it does not happen 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. Although 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. Durability requires the system to save all updates made within a transaction as the transaction successfully completes, thus protecting the integrity of the data.

Only when data is made durable are those specific records accessible through their respective entities from other transactions. Hence, durability also plays a role in isolation. A transaction is not finished until the data is successfully recorded. Ensuring that transactions adhere to the ACID principles requires careful design. The system has to monitor the progress of a transaction to ensure that it does all of its work, that the data is changed correctly, that transactions do not interfere with each other, and that the changes can survive a system crash. Engineering all of this functionality into a system is a lot of work, and not something you would want to reinvent for every business system on which you work. Fortunately, EJB is designed to support transactions automatically, making the development of transactional systems easier. The rest of this chapter examines how EJB supports transactions implicitly (through declarative transaction attributes) and explicitly (through the Java Transaction API, or JTA).

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 explicit APIs such as the Java Transaction Service (JTS). At best, explicit demarcation is difficult if you use the aforementioned APIs, particularly if you are new to transactional systems. In addition, it requires that the transactional code be written within the business logic, which reduces the clarity of the code. We talk more about explicit transaction management and EJB later in this chapter. 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. Declarative transaction management reduces the complexity of transactions for EJB developers and application developers and makes it easier to create robust transactional applications. Where no explicit declarative transaction properties have been defined, EJB will provide a default (which we ll soon see).

Transaction scope is a crucial concept for understanding transactions. In this context, transaction scope refers to managed resources (such as EJBs and entities) that are participating in a particular transaction. In the wrapInTx() method of the test-only TxWrappingEJB, all of the business logic designated in the supplied Callable is executed within a single transaction. When the method invocation completes, the transaction is over and its scope is no longer in context.

As you know, a transaction is a unit-of-work made up of one or more tasks. In a transaction, all the tasks that make up the unit-of-work must succeed for the entire transaction to succeed; in other words, the transaction must be atomic. If any task fails, the updates made by all the other tasks in the transaction will be rolled back or undone. In EJB, tasks are generally expressed as enterprise bean methods, and a unit-of-work consists of every enterprise bean method invoked in a transaction. The scope of a transaction includes every EJB that participates in the unit-of-work. It is easy to trace the scope of a transaction by following the thread of execution. If the invocation of the wrapInTx() method begins a transaction, then logically, the transaction ends when the method completes. The scope of the wrapInTx() transaction would include any transaction-aware service it contains every EJB, entity, or other managed resources. A transaction is propagated to an EJB when that EJB s method is invoked and included in the scope of that transaction. The transaction is also propagated to the persistence context of an EntityManager. The persistence context keeps track of changes made to persistent managed objects and commits them if the transaction succeeds. A transaction can end if an exception is thrown while the wrapInTx() method is executing. The exception can be thrown from any referenced code or the wrapInTx() method itself. An exception may or may not cause a rollback, depending on its type. We discuss exceptions and transactions in more detail later. The thread of execution is not the only factor that determines whether an EJB is included in the scope of a transaction; the EJB s transaction attributes also play a role. Determining whether an EJB participates in the transaction scope of any unit-of-work is accomplished implicitly, using the EJB s transaction attributes, or explicitly, using the JTA.