4 Replies Latest reply on Jun 28, 2012 6:08 PM by swiderski.maciej

    Multiple Threads on a Stateful Session

    r3vans

      I am trying to get an multi-threaded application to run against a single kSession.

      I have made every serviceTask asynchronous but I CANNOT eliminate problems that I think are related to persistence context.

       

       

      Each Handler lools like this:

       

         executeWorkItem(WorkItem workItem, WorkItemManager manager ) {

             WorkHandlerRunner task = new WorkHanderRunner ( kSession, workItem, this)

             threadPoolTaskExecutor.execute ( task )

         }

       

       

      WorkHandlerRunner run looks like this

       

        Constructor saves kSesssion, workItem and workItemHandler

       

         run() {

             WorkItemManager manager = kSession.getWorkItemManager()

             results = runInTransaction ( manager )

             manager.completeWorkItem ( workItem.getId(), results)

          }

       

         @Transactional

          Map<String, Object> runInTransaction ( WorkItemManager manager) {

                  // the doExecute does the business work and does not call into kbpm code

                  return handler.doExecuteWorkItem (workItem, manager)

           }

       

       

      When run it sometimes works for a while but eventually falls over with a mixture of exceptions like

       

      - JPAWorkItemManager.internalWorkItem ( JPAWorkItemManager.java 43 )  - NPA

      - ProcessInstanceImp.getProcess ( kruntime null )

       

       

      I am trying to get a better handle on what happens and when but wonder whether at this light level of reporting someone can spot the obvious mistake.

       

       

      Cheers,

      Richard

        • 1. Re: Multiple Threads on a Stateful Session
          swiderski.maciej

          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?

           

          HTH

          1 of 1 people found this helpful
          • 2. Re: Multiple Threads on a Stateful Session
            r3vans

            Hello again.

             

            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.

            Richard

            • 3. Re: Multiple Threads on a Stateful Session
              r3vans

              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.

               

               

              Richard

              • 4. Re: Multiple Threads on a Stateful Session
                swiderski.maciej

                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?