[jboss-user] [jBPM] - Failover best practice (persistence process and session)

lstrzelecki do-not-reply at jboss.com
Thu Mar 10 11:05:36 EST 2011

lstrzelecki [http://community.jboss.org/people/lstrzelecki] created the discussion

"Failover best practice (persistence process and session)"

To view the discussion, visit: http://community.jboss.org/message/592488#592488

I'm trying to achieve process which will start on restart server. 
For testing purpouses I've created process which logs counter in infinity loop.

Q1: When I should invoke .dispose()? When process goes into loop

StatefulKnowledgeSession session = JPAKnowledgeService.newStatefulKnowledgeSession(knowledgeBase, null, environment);
// getting processInstanceId and sessionId - pestist with JPA

and when i'm *not* invoking .dispose()
counter: 1
counter: 2
counter: 3
counter: 4
counter: 5
counter: 6

but when i invoke .dispose in finally block it ends on first print.

Q2: I created one session for one process. So I allways create new session when starting new process. Is that good solution?
Q3: I've created entity which holds information about session and processInstance (ids both of then). When Spring context starts i read all active processes and rerunes all session by invoking for every session:

JPAKnowledgeService.loadStatefulKnowledgeSession( http://community.jboss.org/message/592488#592488 Failover best practice (persistence process and session), knowledgeBase, null, environment);

After that while starting server every processes(infinity loops) continue printing counter but until I don't invoke .dispose().
So I doubt that I need have open all sessions while server is running.

I'm suppose that engine should care about monitoring process, but nothing like this happens after calling .dispose()

Reply to this message by going to Community

Start a new discussion in jBPM at Community

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-user/attachments/20110310/a9a02724/attachment.html 

More information about the jboss-user mailing list