]
Alejandro Guizar commented on JBPM-1620:
----------------------------------------
I wonder how the entity scheduler service manages to work without the flush in the web
console. Flushing is the technique employed by the old session scheduler service and the
PVM enterprise timer session, and works well in both cases. The multiple last resources
problem manifests itself whenever the EJB timer service participates in the transaction,
not just when flushing; hence I don't regard flushing as a dirty solution.
Nonetheless, flushing the entire session just to get a single record inserted is not cost
effective.
One alternative to flushing the session is to insert the timer record through an EJB
creation method. It might be worth to explore this option to avoid a potentially expensive
flush in the middle of a transaction.
EntitySchedulerService fails with ObjectNotFoundException
---------------------------------------------------------
Key: JBPM-1620
URL:
https://jira.jboss.org/jira/browse/JBPM-1620
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: jPDL 3.2.3
Environment: jbpm-enterprise.ear with jbpm.cfg.xml:
<service name="scheduler"
factory="org.jbpm.scheduler.ejbtimer.EntitySchedulerServiceFactory" />
Reporter: Martin Putz
Assignee: Alejandro Guizar
When a process contains a timer definition, the EntitySchedulerService#createTimer
function fails with the following stacktrace:
2008-08-14 14:42:22,563 DEBUG [org.jbpm.scheduler.ejbtimer.EntitySchedulerService]
creating timer timer(initialReminder,08-08-14 14:42:32,553,Token: 6999)
2008-08-14 14:42:22,563 DEBUG [org.hibernate.jdbc.AbstractBatcher] about to open
PreparedStatement (open PreparedStatements: 0, globally: 0)
2008-08-14 14:42:22,563 DEBUG [org.hibernate.jdbc.ConnectionManager] opening JDBC
connection
2008-08-14 14:42:22,563 DEBUG [org.hibernate.SQL] select nextval
('hibernate_sequence')
2008-08-14 14:42:22,564 DEBUG [org.hibernate.id.SequenceGenerator] Sequence identifier
generated: 7000
2008-08-14 14:42:22,564 DEBUG [org.hibernate.jdbc.AbstractBatcher] about to close
PreparedStatement (open PreparedStatements: 1, globally: 1)
2008-08-14 14:42:22,564 DEBUG [org.hibernate.jdbc.ConnectionManager] aggressively
releasing JDBC connection
2008-08-14 14:42:22,564 DEBUG [org.hibernate.jdbc.ConnectionManager] releasing JDBC
connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)]
2008-08-14 14:42:22,564 DEBUG [org.hibernate.event.def.AbstractSaveEventListener]
generated identifier: 7000, using strategy: org.hibernate.id.SequenceGenerator
2008-08-14 14:42:22,565 DEBUG
[org.jboss.ejb.plugins.cmp.jdbc.JDBCFindByPrimaryKeyQuery.TimerEntityBean#findByPrimaryKey]
Executing SQL: SELECT t0_TimerEntityBean.ID_ FROM jbpm_job t0_TimerEntityBean WHERE
t0_TimerEntityBean.ID_=?
2008-08-14 14:42:22,566 ERROR [org.jbpm.scheduler.ejbtimer.EntitySchedulerService] failed
to retrieve entity for timer timer(initialReminder,08-08-14 14:42:32,553,Token: 6999)
javax.ejb.ObjectNotFoundException: No such entity!
at
org.jboss.ejb.plugins.cmp.jdbc.JDBCFindEntityCommand.execute(JDBCFindEntityCommand.java:64)
at
org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.findEntity(JDBCStoreManager.java:604)
at
org.jboss.ejb.plugins.CMPPersistenceManager.findEntity(CMPPersistenceManager.java:315)
at
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.findEntity(CachedConnectionInterceptor.java:236)
at org.jboss.ejb.EntityContainer.findSingleObject(EntityContainer.java:1099)
at org.jboss.ejb.EntityContainer.findLocal(EntityContainer.java:676)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
...
at $Proxy62.findByPrimaryKey(Unknown Source)
The new record has not been written to the JBPM_JOB table at the time the
timerEntityHome.findByPrimaryKey(new Long(timer.getId())); call is made. I tried adding a
Hibernate session.flush() before, which solved this problem. But as a consequence this
workaround showed the symptoms of multiple 1-phase aware participants enlisting in the
same transaction (
http://wiki.jboss.org/wiki/Multiple1PC), so there must be a cleaner
solution to it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: