\n
\nFirst, if you’ve missed the articles about Spring annotation, have a look here:<\/p>\n
- \n
- Spring @Transactional explained<\/a><\/li>\n
- Spring @PersistenceContext\/@PersistenceUnit explained<\/a><\/li>\n<\/ul>\n
The following implementation is based on Spring 3.0.5<\/strong> official release + JPA 2\/Hibernate 3.5.2<\/strong> in a WEB J2SE<\/strong> environment. If you are running applications on a J2EE platform, you should rely on transaction management facilities provided by the J2EE engine itself<\/p><\/blockquote>\n
Before going further, let’s define some notions:<\/p>\n
- \n
- by session<\/strong><\/em> we mean Hibernate session<\/strong> (e.g. equivalent of entity manager)<\/li>\n
- by user session<\/strong><\/em> we mean the user data context on the server. It includes all user data and session-scoped beans<\/li>\n
- by persistence context<\/strong><\/em>, we mean a set of entities that are managed by the EntityManager<\/strong>. Sometimes people tend to use EntityManager when they mean persistence context.<\/li>\n
- by transaction<\/strong><\/em> we mean JDBC transaction<\/strong>, not user transaction (unit-of-work <\/em>or conversation<\/em>). A transaction<\/strong> can be started by an EntityManager<\/strong> within a persistence context. Within the same persistence context, several transactions<\/strong> can exist, provided that their lifespan does not overlap since JPA does not support nested transactions<\/strong><\/li>\n<\/ul>\n
<\/p>\n
I The need for a long\/extended session<\/h1>\n
The problem with the classical session-per-request<\/em> or OSIV<\/strong> (Open Session In View) patterns is that for each new request made by the client browser to the server, a new EntityManager<\/strong> is created, attached to the current Thread using a ThreadLocal and is passed along all layers down to the DAOs. Once the response is sent back to the client browser, this EntityManager<\/strong> is closed so all entities that have been retrieved from the database are now in detached<\/strong> mode.<\/p>\n
There are many drawbacks being in detached mode:<\/p>\n
- \n
- the state of entities is not managed<\/em>. Any modification to the field or collections on the entities is ignored by Hibernate while in detached mode. The next time they are re-attached to another EntityManager<\/strong>, all the modifications are lost<\/li>\n
- the re-attachment of the entity itself is not that easy with the current state of JPA specs. JPA API does expose\u00a0 a detach()<\/em> method on EntityManager<\/strong> but there is no re-attach()<\/em>or something similar.\n
- \n
- one solution is to use merge()<\/em> but merge()<\/em> is not re-attaching your old detached entity, it copies all its state to a fresh entity created from scratch, synchronizing it with the database and returns the Java reference of the new entity. If your old detached entity is still referenced by other classes (service\/DAO\/presentation layers) you should update the reference with the new entity, which is quite cumbersome<\/li>\n
- the other work-around is to use session.saveOrUpdate(detachedEntity) <\/em>but it is worst because it will trigger sometimes UPDATE statement to the database since Hibernate does not know whether the state of this entity has changed or not while it was detached. Furthermore you need to do it on all detached entities so somehow you need to keep track (in a List) of all entities that may be detached to re-attach them automatically. Again this is very error-prone<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n
The ultimate idea is to avoid detaching entities, keep them in the persistence context and let the EntityManager<\/strong> manage as long as the user unit-of-work<\/em> lasts.<\/p>\n
The difficulty now is where to store this opened EntityManager<\/strong> whose lifespan spreads across several client-server requests. Furthermore, we need to bind each living EntityManager to the correct user session. The natural placeholder is the HttpSession<\/strong> map.
\n <\/p>\nII\u00a0 Pre-requisites<\/h1>\n
With global conversation, we need to:<\/p>\n
- \n
- Clearly identify end-user conversation scenarios<\/strong><\/span>. An extended persistence context does not make sense if the developer cannot sketch out distinct web navigation scenarios and use cases.<\/li>\n
<\/p>\n
- List all possible entry points for new conversations and their exit points<\/span> to flush and close the EntityManager<\/span><\/strong>. Every conversation should have an exit point otherwise the EntityManager<\/strong> will never be closed and you’ll run into big trouble (OutOFMemoryException<\/em> at least).<\/li>\n
<\/p>\n
- Manage carefully the growth of the persistence context<\/strong><\/span>. Since the EntityManager<\/strong> lives across several user Web requests, the persistence context tends to grow bigger and bigger. You should load in the persistence context as few entities as possible, only those that are necessary for the current conversation.<\/li>\n
<\/p>\n
- Usage of secondary level cache is strongly advised<\/span><\/strong> to discharge the EntityManager<\/strong> the burden of caching frequently used referential data.<\/li>\n
<\/p>\n
- When you need to request data in the DB necessary for the logic of the user operations (functional code<\/em> or label<\/em> for\u00a0 instance), prefer<\/strong> scalar queries<\/a><\/strong><\/span> over object queries<\/strong><\/span>. Contrary to the latter, scalar results are not kept in the persistence context. If you run frequently some queries, consider using query cache<\/strong><\/a>.<\/li>\n
<\/p>\n
- Consider creating additional temporary<\/strong><\/span> EntityManagers<\/strong><\/span> to load specifies entities, read their value and close the temporary EntityManager<\/strong>. This EntityManager<\/strong> is completely independent and isolated from the main EntityManager<\/strong> attached to the\u00a0ThreadLocal<\/strong> in use. Look at Temporary Conversation with Spring AOP<\/a> for more details.<\/li>\n
<\/p>\n
- Consider detaching some entities when they are no longer used<\/strong><\/span>. For this, use the em.detach(entityToDetach)<\/em> method. Beware of CascadeType<\/strong> configuration for collection associations in the entities candidate to be detached.<\/li>\n
<\/p>\n
- Last but not least , find a convenient way to send the end-of-conversation signal<\/strong><\/span> to flush the persistence context and close the EntityManager<\/strong>. It is trickier than expected, especially when the signal is triggered at the Web tier and needs to be carried down to the DAO or servlet filter layer. Some available options : use another ThreadLocal<\/strong> to carry the signal (again!), use global variable,\u00a0 rely on AOP or carry a parameter along all method (brute force solution)<\/li>\n<\/ol>\n
<\/p>\n
III Navigation models<\/h1>\n
As stated above, a clear navigation model for the GUI should be scketched out to help identifying entry\/exit points for the global conversation. Below we introduce two types of navigation.<\/p>\n
A Generic navigation<\/h2>\n
This is the most common type of navigation model. There are multiple entry and exit points. Some screens act as entry point for many scenario, some others act as exit point.<\/p>\n
![\"\"](\"https:\/\/www.doanduyhai.com\/blog\/wp-content\/uploads\/2012\/02\/global_navigation.png\" "\\"Global_Navigation\\"")
<\/a><\/p>\nB Cyclic navigation<\/h2>\n
In this case, there is a single screen which is the pivot point for different navigation scenarios. Each new scenario starts at the same screen so the exit point for one conversation does match with the entry point for another.<\/p>\n
![\"\"](\"https:\/\/www.doanduyhai.com\/blog\/wp-content\/uploads\/2012\/02\/cyclic_navigation.png\" "\\"Cyclic_Navigation\\"")
<\/a><\/p>\nIII Design<\/h1>\n
A Main actors<\/h2>\n
\nThis sample implementation consists of 4 actors:<\/p>\n- \n
- ConversationManager<\/strong>: the interface responsible for the management of the global conversation.<\/li>\n
- ConversationRepository<\/strong>: repository interface to store the Entity Manager for the global conversation<\/li>\n
- ConversationAnnotationProcessor<\/strong>: interface responsible for the interception of conversation demarcations<\/li>\n
- AbstractConversationFilter<\/strong>: abstract class responsible for re-attaching\/detaching the Entity Manager to the Thread Local between each request to the server<\/li>\n<\/ol>\n
<\/p>\n
B Annotation<\/h2>\n
For the conversation demarcation, we introduce the following annotations:<\/p>\n
- \n
- @BeginConversation<\/strong>(entityManagerFactory=”myEntityManagerFactory1″)<\/em><\/li>\n
- @EndConversation<\/strong>(entityManagerFactory=”myEntityManagerFactory1″)<\/em><\/li>\n
- @EndCyclicConversation<\/strong>(entityManagerFactory=”myEntityManagerFactory2″)<\/em><\/li>\n<\/ul>\n
The first two annotations are used by global conversations. The last one is only usefull for cyclic conversations.
\n <\/p>\nC ConversationManager<\/h2>\n
![\"\"](\"https:\/\/www.doanduyhai.com\/blog\/wp-content\/uploads\/2012\/02\/conversationmanager.png\" "\\"ConversationManager\\"")
<\/a><\/p>\nThe ConversationManager<\/strong> interface exposes the following attributes & methods:<\/p>\n
- \n
- repository<\/strong>: reference to a ConversationRepository instance<\/li>\n
- beginConversation(Object token, EntityManagerFactory emf)<\/strong>: start a new conversation using provided emf<\/em> to create a global Entity Manager and the token<\/em> to register it in the repository<\/em><\/li>\n
- endConversation(Object token, EntityManagerFactory emf)<\/strong>: end a conversation. Remove the registered Entity Manager from the repository using the token<\/em> as search key<\/li>\n
- reattachEntityManager(Object token, EntityManagerFactory emf)<\/strong>: look uo the global Entity Manager in the repository<\/em> using the token<\/em> then attach it to the Thread Local (using Spring TransactionSynchronizationManager<\/strong>)<\/li>\n
- detachEntityManager(EntityManagerFactory emf)<\/strong>: detach the global Entity Manager from the Thread Local (using Spring TransactionSynchronizationManager<\/strong>)<\/li>\n
- findEntityManager(Object token)<\/strong>: helper method to look for the Entity Manager in the repository<\/em> using the token<\/em><\/li>\n
- hasConversation(Object token)<\/strong>: helper method to check whether there is an on-going conversation with the token<\/em> <\/li>\n<\/ul>\n
<\/p>\n
D ConversationRepository<\/h2>\n
![\"\"](\"https:\/\/www.doanduyhai.com\/blog\/wp-content\/uploads\/2012\/02\/conversationmanager_conversationrepository1.png\" "\\"ConversationManager_ConversationRepository\\"")
<\/a><\/p>\nThe ConversationRepository<\/strong> interface exposes 3 methods:<\/p>\n
- \n
- registerEntityManager(Object token, EntityManager em)<\/strong>: register the provided Entity Manager in the repository with token<\/em> as search key<\/li>\n
- unregisterEntityManager(Object token)<\/strong>: remove the Entity Manager associated to the token<\/em> from the repository<\/li>\n
- findEntityManager(Object token)<\/strong>: self-explanatory<\/li>\n<\/ul>\n
There are several possible implementations for this interface. The default implementation is the HttpSessionRepository<\/strong>. It uses the current user HTTP session as storage and keeps an internal map of all Entity Managers.
\n <\/p>\nE ConversationAnnotationProcessor<\/h2>\n
- unregisterEntityManager(Object token)<\/strong>: remove the Entity Manager associated to the token<\/em> from the repository<\/li>\n
- beginConversation(Object token, EntityManagerFactory emf)<\/strong>: start a new conversation using provided emf<\/em> to create a global Entity Manager and the token<\/em> to register it in the repository<\/em><\/li>\n
- @EndConversation<\/strong>(entityManagerFactory=”myEntityManagerFactory1″)<\/em><\/li>\n
- ConversationRepository<\/strong>: repository interface to store the Entity Manager for the global conversation<\/li>\n
- List all possible entry points for new conversations and their exit points<\/span> to flush and close the EntityManager<\/span><\/strong>. Every conversation should have an exit point otherwise the EntityManager<\/strong> will never be closed and you’ll run into big trouble (OutOFMemoryException<\/em> at least).<\/li>\n
- the other work-around is to use session.saveOrUpdate(detachedEntity) <\/em>but it is worst because it will trigger sometimes UPDATE statement to the database since Hibernate does not know whether the state of this entity has changed or not while it was detached. Furthermore you need to do it on all detached entities so somehow you need to keep track (in a List) of all entities that may be detached to re-attach them automatically. Again this is very error-prone<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n
- the re-attachment of the entity itself is not that easy with the current state of JPA specs. JPA API does expose\u00a0 a detach()<\/em> method on EntityManager<\/strong> but there is no re-attach()<\/em>or something similar.\n
- by user session<\/strong><\/em> we mean the user data context on the server. It includes all user data and session-scoped beans<\/li>\n
- Spring @PersistenceContext\/@PersistenceUnit explained<\/a><\/li>\n<\/ul>\n
![\"\"](\"https:\/\/www.doanduyhai.com\/blog\/wp-content\/uploads\/2012\/02\/conversationmanager_conversationannotationprocessor.png\" "\\"ConversationManager_ConversationAnnotationProcessor\\"")
<\/a><\/p>\n![\"\"](\"https:\/\/www.doanduyhai.com\/blog\/wp-content\/uploads\/2012\/02\/conversationmanager_conversationfilter.png\" "\\"ConversationManager_ConversationFilter\\"")
<\/a><\/p>\n