[
http://jira.jboss.com/jira/browse/JBSEAM-2975?page=comments#action_12412301 ]
stefan meyer commented on JBSEAM-2975:
--------------------------------------
Please ask questions if my goal/motivation is not clear.
Using the same entityManager for Seam and jbpm
----------------------------------------------
Key: JBSEAM-2975
URL:
http://jira.jboss.com/jira/browse/JBSEAM-2975
Project: Seam
Issue Type: Feature Request
Components: BPM
Affects Versions: 2.0.1.GA
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;
}
...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira