EJB Extended and seam-managed persistence context

This article will briefly discuss my understanding of the differences between the two persistence context and seam-managed persistence in EJB 3.0, the problems to be solved, and the problems I am wondering about.

Persistence context for EJB 3.0 (JPA)

When you use EJB 3.0, you will notice that there are two types of container management persistence context in EJB 3.0, one is Transaction and the other is Extended. This is a less-than-Hibernate notion that session does not have two different types, and most importantly, the session is not container-managed, and the container here refers to the APP server container. Here for the time being not to discuss the similarities and differences between persistence context and session, mainly to talk about the difference between the two persistence context. The students who have learned ORM know that when the persistence context is open, model is in the state of being managed, and when persistence is closed, model is in the Detached state.

These features are the same for the persistence context of the Transaction or Extended, except that the persistence context is opened and closed. Because in most cases the persistence context is managed by the container (if you are not too tired to control the persistence context), the code that opens or closes the persistence context is not visible in the EJB 3.0 application ( The same applies to spring + Hibernate, and Hibernate session management can be given to spring.

In fact, the difference between Transaction and Extended persistence context is also when the container opens or closes the persistence context. The opening and closing of the Transaction type persistence context is synchronized with the opening and closing of the transaction. That is, the persistence context begins after a transaction is started, and the corresponding persistence context is closed when the transaction is closed.

The opening and closing of the Extended type persistence context is synchronized with the lifecycle of the Stateful session Bean and is spanned by transactions. That is to say, the persistence context exists from the initialization of the SFSB until it is destroyed. You can perform a write operation outside of a transaction, but this does not perform a real database operation, the write operation is only placed in the queue until the next transaction, the write operation is actually executed. The difference between the two is simply that the Extended persistence context exists for a longer time. So why should there be two different persistence context?

When a WEB request arrives, the server opens a thread that might invoke a transaction method, a transaction that begins, and when the request ends, the thread closes and the transaction ends. Because the life cycle of the Transaction type persistence context is within the transaction scope, the end of a WEB request also means that the corresponding persistence is closed. Since most Web applications can complete a separate operation within a single Web request, the persistence context of Transaction is applicable in most cases. But for some complex applications, one operation needs to span multiple requests. In this case, if you still use the persistence context of transcation, because each request is completed, the corresponding persistence context are closed, the corresponding Model will become Detached state. If the next request still needs the Model that has changed to Detached state, the load will need to be renewed using the merge () method to persist. A slight discomfort will result in lazyinitializationexception and nonuniqueobjectexception. This also increases the complexity of the operation.

If you use the Extended persistence context, you can solve these problems. Because the life cycle of the Extended persistence context is synchronized with the SFSB lifecycle, so long as multiple requests are made to the same SFSB method, how many times the request, the persistence is always the same, where the Mo Del is also always managed. It solves the problem of transmission between the persistence context online, and there is no lazyinitializationexception and nonuniqueobjectexception problem.