[jbpm-issues] [JBoss JIRA] Moved: (JBPM-1770) Using the same entityManager for Seam and jbpm

Using the same entityManager for Seam and jbpm ---------------------------------------------- Key: JBPM-1770 URL: https://jira.jboss.org/jira/browse/JBPM-1770 Project: JBoss jBPM Issue Type: Feature Request Security Level: Public(Everyone can see) Reporter: stefan meyer I wrote an entry in the forum and was asked to create a JIRA issue. Following is the forum entry and my code. The code is ugly whenever calls come via MDBs. ManagedPersistenceContext.beforeCompletion does not work nicely with this implementation. Because I cannot get the entityManager anymore. Even if the code was called in destroy the entitymanager would be gone. If ManagedJbpmContext was in conversation scope and depended on ManagedPersistenceContext and the dependency would lead to the destruction of managedJbpmContext first, then things would be better. The problem is actually only that Jbpm-DbLogging does not work. Maybe that should be fixed. Or Maybe the Jbpm people should work on it. " Jbpm and seam using the same entityManager makes sense, because storing entities in variable context and refernecing processInstance or token from entities is possible. I have the following problem though. My SeamPersistenceService Implementation of Jbpm's PersistenceService is closed with the destruction of the ManagedJbpmContext. Since ManagedJbpmContext is in scope EVENT and entityManager in scope CONVERSATION the entityManager is destroyed before. Jbpm tries to save the log entities upon close and thus fails because the seam managed entityManager is gone and even closed. In my scenario it would help to close JbpmContext in the destroy Method of managedJbpmContext. Transactions and Connections are managed by JbpmContext anyways. Unfortunately direct access to the entityManager will not be possiblle in destroy because the entityManager is removed from Contexts before the ManagedJbpmContext. Maybe ManagedJbpmContext should also be in the Conversation scope. Could you include an alternative version of ManagedJbpmContext that works with a SeamPersistenceService? " Here is my Implementation of Jbpm's PersistenceService that uses a seam managed EntityManager (actually the wrapped hibernate session): package xx.jbpm.persistence.seam; import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; import org.hibernate.Session; import org.jboss.seam.Component; import org.jboss.seam.ScopeType; import org.jboss.seam.contexts.Contexts; import org.jbpm.persistence.db.DbPersistenceServiceFactory; import org.jbpm.persistence.jta.JtaDbPersistenceService; public class SeamPersistenceService extends JtaDbPersistenceService { private static Log log = LogFactory.getLog(SeamPersistenceService.class); public SeamPersistenceService(final DbPersistenceServiceFactory persistenceServiceFactory) { super(persistenceServiceFactory); } @Override public void close() { // session is not closed here. super.close(); } @Override public Session getSession() { boolean initialized = Contexts.isApplicationContextActive(); if (initialized) { Session hibernateSession = (Session) Component.getInstance("hibernateSession", ScopeType.EVENT); if (hibernateSession == null || !hibernateSession.isOpen()) { // see comment in else clause return new DummySession(); } else { return hibernateSession; } } else { // seam is not active any more but entityManager is closed in transaction synchronization. // unfortunately ManagedJbpmContext wants to flush the entityManager in beforeCompletion, but we can't get // it via seam anymore. This is probably happening right now. Also saving of instances might happen here. These // are all persistent entites - that is why seam ignores it. Except for the log entries - those get lost // when db logging is used. return Dummy Session return new DummySession(); } } } Extract from DummySession: ... public Serializable save(final Object object) throws HibernateException { try { Method getIdMethod = object.getClass().getMethod("getId", new Class[0]); Object value = getIdMethod.invoke(object, new Object[0]); if (value != null && ((Number) value).intValue() == 0) { Logger.getLogger("dummy session").warn("not saving transient entity " + object.getClass().getName()); } } catch (Exception e) { Logger.getLogger("dummy session").warn("cannot check state of entities " + object.getClass().getName(), e); } return null; } ...