Trouble creatinga timer

[russelldb]

Hi All,
I have read the userguide and tried to create a Timer. I tried doing as is done in the jbpm testsuite and I have tried doing it like this

<state name="Awaiting Encryption">
 <node-enter>
 <create-timer name="checkEncrypted"
 duedate="10 business seconds"
 repeat="10 business seconds">
 <action class="uk.co.link.atminstalls.actions.CheckATMEncryptedAction"/>
 </create-timer>
 </node-enter>
 <node-leave>
 <cancel-timer name="checkEncrypted"/>
 </node-leave>
 <transition to="Add To NCPCOM ?"/>
 <transition name="time-out" to="Check-encrypted-task"/>
 </state>

And neither gives me a row in the JBPM_TIMER table. And neither causes my ActionHandler to be called.

When I check the ProcessInstance the node that the root token is in is the "Awaiting Encryption" yet the action is never fired.

My aim is to have the token enter the node. Fire the action after 10 seconds and keep firing the action every 10 seconds until the end of time. Is this possible, do you know how ? Is it better to have an action on the node that programmatically creates a Timer and starts it ?

The SchedulerServlet is running but there is no row in the database for it to activate.

Many thanks in advance if you can help.

Regards

Russell

[alkero]

May be you can try this way:

<state name="Awaiting Encryption">
<timer name='checkEncrypted duedate='10 business seconds' repeat='10 business seconds'>
<action class="uk.co.link.atminstalls.actions.CheckATMEncryptedAction"/>
</timer>
<node-leave>
<cancel-timer name="checkEncrypted"/>
</node-leave>
<transition to="Add To NCPCOM ?"/>
<transition name="time-out" to="Check-encrypted-task"/>
</state>

You should save the process instance just before the Awaiting Encryption state.


Regards,
David

[russelldb]

I can't. The previous node is a join. So I specify an action on the transition to the "Awaiting Encrypion" node and the action saves the process instance

JbpmSession session = sf.openJbpmSession();
 session.beginTransaction();


 session.getGraphSession().saveProcessInstance(executionContext.getProcessInstance());

And I get an exception

ERROR [org.jbpm.db.GraphSession] org.hibernate.HibernateException:
Illegal attempt to associate a collection with two open sessions

Is there anyway to get the current jbpmSession from the ExecutionContext and save me openinga new session from within a process instance ?

Also, I don't understand why I have to. I don't save the process instance when a TaskNode creates a Task Instance but the task instance finds its way into the database ?

Cheers

Russell

[russelldb]

Ah. Ok. I did it. Rather than trying to save the process instance in an ActionHandler I am doing elsewhere (outside the process).

It seems to be a bit of a hack though.

Thanks for your help.

Russell

[alkero]

I agree, it's a hack, but unfortunately timers are updated only with a saveProcessInstance or a signal.

However I think you can save the process instance directly in the action handler.

Try something like:

JbpmSession.getCurrentJbpmSession().getGraphSession().saveProcessInstance(executionContext.getToken().getProcessInstance());



Regards,
David

[tom.baeyens]

I agree, it's a hack, but unfortunately timers are updated only with a saveProcessInstance or a signal.

what is wrong with that approach ? how could we improve it ?

regards, tom.

[russelldb]

Hi,
I think it is a hack because when a TaskNode is entered and a Task element is encountered a a TaskInstance record is created in the db without the developer having to code a saveProcessInstance. When a Timer is encountered a Timer record does not get inserted in the db unless I saveProcessInstance first. It is counter intuitive is all I mean when I say a "hack".

If it is the way to do then I will do it that way as I am just happy to have Jbpm.

Cheers

Russell

[tom.baeyens]

the task instance is also not entered in the database until the task instance is saved. in some scenarios, hibernate might detect the changes automatic, but that approach will not work in the general case, i think. so you have to save (OrUpdate) the process instance to save the task instances.

the difference is that task instances are linked in the process instance object graph. and hibernate will save them by cascading. for timers this is different. as we plan to support multiple timer implementations (our own + wrapping ejb timer service, ...) Also this should be made as a part of the transaction. This just as a bit of background around the current solution.

in jbpm 3.1 we are working on thread context stuff that improves/simplifies the persistence handling. there might be some options on changing. But i don't see yet what you consider a hack and more importantly, how we could improve our current implementation.

regards, tom.

[russelldb]

No disrespect intended Tom but if you can't see what I think is hack from mnot reading it. By behaviour, as far as I have observed, TaskInstances are created automatically and Timers are not. Both "look" alike when you create them in jpdl so it is counter intuitive and undocumented that I must perform a save on the process instance before a Timer is persisted when I don't "need" to do the same for Tasks

You have explained that it is due to my lack of understanding of Hibernate and Jbpm that it looks like a hack and I am content from your explanation that what from a user perspective seems hacky is in fact not at all. It makes sense now.

I hope that I have not caused any offence but as an end user it seemed like a hack to have to save the process instance for in one case but not in another, now it is explained it does not seem like a hack as in fact one should save the process instance in both cases.

To answer your other question "how could we improve..." well I would saythe obvious answer that a manager/customer would make is: automatically persist TaskInstances and Timers. As a developer I don't know how to but that is another question.

Cheers and thanks again for the great product

Russell

[tom.baeyens]

now it is explained it does not seem like a hack as in fact one should save the process instance in both cases.

i should work on my hibernate skills so that i know when a save is necessary. i took it for granted that you have to save. when i find the time i'll do some trials to see how when a save (OrUpdate) is unnecessary and how the cascading works in that scenario...

agreed, sometimes having to save and sometimes not looks like a hack... or at least it's inconsistent.

thanks !

regards, tom.

[alkero]

The problem is that a timer can be inactive as the associated token is on the associated node.
It seems to be really disturbing for beginners, who lost time for resolving the problem.

May be a doc update or a wiki page on this particular point can be useful ?


Regards,
David

[russelldb]

Wiki page sounds good. I checked the docs and Wiki before posting and I think most people do. I've never contributed to the wiki before so I'd rather you did it but if you can't I'll give it a go.

[alkero]

I have not a lot of available time and my english is sometimes strange, so please feel free to do it !


Thanks,
David

[camunda]

Hi everybody. This "workaround" describe here works fine for many use cases :-)

But it is limited: If a process starts a sub-process, the

session.getGraphSession().saveProcessInstance(pi);

only saves the logs & timers for the parent process, not the sub-process!

I have made a JIRA-Issue for that:
http://jira.jboss.com/jira/browse/JBPM-477

Out temporary fix is also there....