1 of 1 people found this helpful
Where do you run this - in an application server?the null pointers are probably caused by transaction synchronization that disconnects process instance from the the session. What you could try it to manage your transaction in the async thread, meaning that you control start and commit of the transaction so all the work done by jbpm will join that single transaction.
Would be good if you could provide some tests/simple app that illustrates this so I could give a try to look into what is going on there. I believe this is kind of continuation of the other threads about multiple sessions managements, right?
Since I wrote I think i have made some progress. I think it points at the same problem as you suggest but my approach is a bit different.
I have a single thread starting the process and then handlers are as above. I originally had an active transaction when starting the process and now I have ensured that this transaction is completed before starting the process. There is now no txn running when I call startProcess or completeWorkItem. I think this ensures that jbpm manages it's own transactions and things are looking up so far.
Does that make sense?
Thanks for your help.
PS. I missed your question about the other discussion threads. It's related, yes. In the other discussions I was trying to have multiple kSessions in different threads so that my service task handlers could get away with being slow. I had trouble with that so I turned the problem inside out. I now have one session but use the threads to make the task handlers asynchronous so that I don't tie up the session.
yup that sounds good to me and if I understood correctly that is the default scenario where jbpm will have transaction boundary on each command.
Does it work better now, by that I mean acceptable in case of throughput?