Transaction Management with JBoss Seam + JPA (Hibernate) like Spring Framework

I'm a fan of using Spring framework for all my projects, but unfortunately on my current project, I have to add a module to an existing app already developed using JBoss Seam EJB3 and Hibernate, so this is what I did to work with the same model of ServiceImpl that Spring uses

This is the DAO (Existing) - I just added the save method
@Name("purchaseDao") @AutoCreate @Stateless @TransactionAttribute(TransactionAttributeType.REQUIRED) @TransactionManagement(TransactionManagementType.CONTAINER) public class PurchaseDAO_EJB3_Impl implements PurchaseDAO { private static Log log = LogFactory.getLog(PurchaseDAO_EJB3_Impl.class); @PersistenceContext(type = PersistenceContextType.TRANSACTION) private EntityManager em; .... public void save(Purchase instance) { log.debug("Saving "+instance); em.persist(instance); log.debug("Saved"); } } And this will be My Service (I will not include the Interfaces)
@Name("enrollmentDetailsServiceBean") @AutoCreate public class EnrollmentDetailsServiceImpl implements IEnrollmentDetailsService { private static Logger log = Logger.getLogger(EnrollmentDetailsServiceImpl.class); @In("purchaseDao") private PurchaseDAO purchaseDAO; /* * Service method which will handle the Transaction */ @Transactional(TransactionPropagationType.REQUIRED) public Boolean saveEnrollmentDetails(EnrollmentDetails enrollmentDetails) throws Exception { Boolean result = false; try{ log.debug("Transform "+enrollmentDetails+" into POJOs"); Purchase purchase = Transformer.transform(enrollmentDetails); log.debug("Start saving PURCHASE, PURCHASE_MODULE & TRANSACTION"); purchaseDAO.save(purchase); log.warn("Insert another POJO (which already exists on the table) to break this thing :P"); Purchase purchase2 = new Purchase(); purchaseDAO.save(purchase2); log.debug("Inserts completed!"); result = true; }catch (Exception ex) { log.error("Error while saving EnrollmentDetails into DB: PURCHASE, PURCHASE_MODULE, TRANSACTION",ex); throw ex; } return result; } }
By doing this we have the same model of Tx Management - Just by adding the 1 annotation to the method!!! Cool Isn't it?
Also, in case that you want to make your Tx ReadOnly, just add this annotation to your method (also)

org.jboss.seam.annotations.ReadOnly

Unfortunately the documentation for JBoss Seam is really poor on this aspect, so If anybody finds anything that could be improved, please let me know)

Annotation-Based Transactions

Spring provides several different approaches to transaction management:

• Programmatic: You can write your transactions using Java source code directly. Normally you wouldn't do this unless you needed fine-grained control over some particular transaction.
• Declarative: You can declare transaction definitions in either a centralized way using XML or in a distributed way using annotations:
  • XML-based: You can configure transactions in Spring's centralized application context file. Once again you have options:
    • Proxy-based: In this approach you wrap your service beans with transactional proxies. The proxy and the service bean both implement the same Java interface so the application can't tell them apart. This is a fairly verbose approach with respect to the actual context configuration though there are techniques you can use to streamline the configuration.
    • AOP-based: Here you define AOP aspects to endow your service beans with transactional semantics. Not quite as verbose as the proxy-based approach.
  • Annotation-based: You can use Java 5 annotations to distribute transaction configuration across Java classes.

With Spring, you typically apply transaction annotations either to Java interfaces for service beans, or else to the service beans themselves. If you apply the annotations to the interfaces then the transaction definition holds true for any classes implementing those interfaces. We'll do that here, but remember that you can apply the annotations to the service beans themselves as well.
Here's an interface for a simple article service. This service allows the application to get an article by ID, and also to post a comment for a given article. package mx.com.myapp.business.service; import org.springframework.transaction.annotation.Isolation; import org.springframework.transaction.annotation.Propagation; import org.springframework.transaction.annotation.Transactional; import mx.com.myapp.persistence.domain.Article; import mx.com.myapp.persistence.domain.Comment; @Transactional( propagation = Propagation.REQUIRED, isolation = Isolation.DEFAULT, readOnly = true) public interface ArticleService { Article getArticle(long articleId); @Transactional(readOnly = false) void postComment(long articleId, Comment comment); }
The first thing to notice is again just how ridiculously simple this is. I probably don't need to explain it but I will anyway just to be safe. The @Transactional annotation we define on the interface is setting default values for the various methods that form the interface. So we are saying here that unless the method itself specifies otherwise, we want Propagation.REQUIRED for the propagation behavior, we want the default isolation level, and we want to flag methods as read-only.
The only other piece to mention is that I've overridden the readOnly setting for the postComment method since that's obviously a write method.
If it could be any simpler I'm not sure how. Now let's look at the Spring configuration file.

<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context" xmlns:aop="http://www.springframework.org/schema/aop" xmlns:tx="http://www.springframework.org/schema/tx" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.5.xsd http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.5.xsd"> <!-- Wire beans here --> ... <bean id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager"> ... </bean> <!-- This tells Spring to activate annotation-driven transactions --> <tx:annotation-driven/> </beans> That's it—really! Make sure you include both the aop and tx namespaces and schema locations since that's where the magic lives. You have to wire your beans up just like you normally would. And you have to provide a transaction manager of one kind or another. I'm using the Hibernate 3 HibernateTransactionManager but use whatever you want. If you give your transaction manager the id transactionManager, then you can take advantage of a little Spring convention-over-configuration: <tx:annotation-driven> will pick that up automatically. (And if you want to call your transaction manager something else, that's fine too. Just reference that ID using the transaction-manager attribute of the <tx:annotation-driven> element.)
Oh, the <tx:annotation-driven> element just tells Spring that you want it to pick the transaction definitions up from the Java annotations. I'm not sure how it works behind the scenes, but I think Spring will run through the beans in your context and create the necessary transaction aspects. Not positive about that—if you know the details, I'm interested—but in any case you end up with annotation-driven transactions. Nice!

Transaction Basics

The core idea behind a transaction is that it's a complex operation completed as an all-or-nothing set of simpler operations. If one of the simpler operations fails, then none of the operations should be applied.
The classic example is making a purchase, and indeed this is probably where the name "transaction" comes from. There are several steps:

1. Pull funds from buyer's account
2. Add funds to seller's account
3. Decrease product inventory

A failure could happen at any of those steps. For example, at step 1, if the buyer doesn't have enough money, then the transaction should fail. (We wouldn't add funds to the seller's account and we wouldn't decrease product inventory.) At step 2, if the seller's account has been frozen due to suspected involvement in illegal activities, then the transaction should fail. At step 3, if the product is out of stock, then again the transaction should fail.

ACID Properties

ACID is an acronym that stands for atomic, consistent, isolated and durable. An operation is a transaction if and only if it has these four characteristics:

• Atomic: This is the aforementioned all-or-nothing property. Even though a transaction comprises multiple operations, it is completed as a single logical unit of work. Either the whole thing succeeds or none of it does.
• Consistent: We want our "transactional resource" (which in most cases means our database) to be consistent with reality. So for example if I have 4,132 widgets in stock after I sell you five of them, then I want the database to say that I have 4,132 widgets in stock after I run a sell(you, 5, widget) transaction. The consistency property means that after a transaction completes, the database (or whatever transactional resource we're using) matches up with the real world.
• Isolated: In general we want to be able to run lots of transactions against the database at the same time, and we don't want to make a big mess out of things in the process. The isolation property means that when you run a transaction, it achieves its results without interference from other transactions. That doesn't mean that the transactions can't run concurrently—it just means that the transactions shouldn't corrupt each other in the process. In practice it's nontrivial to strike the right balance between concurrency and isolation; transactions however exhibit some level of isolation, and well-designed transactions exhibit the "right" amount of isolation.
• Durable: This just means that after a transaction has ended, its results are made persistent. Probably they would have called this property "persistent" instead of "durable", but "ACIP" is not as cool as "ACID".

Defining Individual Transactions

Now that we know what transactions are, we need to understand how individual transactions are actually specified. Defining a transaction involves picking a chunk of code (maybe a method, maybe a set of methods, maybe a block of code inside a method) and setting values for the following five parameters:

• Propagation behavior: When defining a transaction we must specify its "boundaries": where does the transaction start and where does it end? In Spring (and also in EJB), the boundaries of a transaction may or may not coincide with the boundaries of a Java method. In one respect this is not unlike using the synchronized keyword: if one synchronized method calls another on the same class, then the protected scope includes both methods, not just one, and so the boundaries do not coincide with a single method. But the difference is that with transactions you have a lot more flexibility as far as defining the boundaries. Certainly it is possible to enter a transaction starting from one method and then include additional method calls within the scope of that initial transaction. But you can do other things too, such as declare that calls to other methods open up new transactions, or that a given method must always run within the scope of an existing transaction, etc. I won't go over all the options here but there are seven and you can see them here: transaction propagation options. Probably PROPAGATION_REQUIRED is the most typical.
• Isolation level: I mentioned above that in practice concurrency trades against isolation. (Once again there's an analogy with threads, incidentally.) You can specify the level of isolation you need for a given transaction; the general rule of thumb is assign the weakest isolation level you can safely get away with so as to maximize concurrency. Again I won't go into the details but you can find them here: transaction isolation levels. The most typical cases are ISOLATION_READ_COMMITTED and ISOLATION_REPEATABLE_READ. The ISOLATION_READ_UNCOMMITTED is so weak as to be almost useless in practice, and ISOLATION_SERIALIZABLE is so strong that you don't want to use it unless you really, really need the safety it provides: it's a concurrency-killer.
• Timeout: Transaction timeouts allow the calling application to give up if the database hasn't completed the transaction within a specifiable interval of time.
• Read-only: This flag indicates whether the transaction will be, well, read-only. If so, you can flag it as such and the underlying database or other resource can apply optimizations based on that fact.
• Rollback behavior: By default, both Spring and EJB roll back a transaction (i.e., cancel it without applying any of the changes) when runtime exceptions, but not when checked exceptions occur. You can modify that behavior.