1 Reply Latest reply on Sep 10, 2006 2:13 PM by Koen Aers

    Accessing the underlaying hibernate session / transaction

    Harald Strack Newbie

      Hi all!

      I am evaluating JBPM for as the workflow engine for my company. I am quite enthusiastic about this nice piece of software. Since a week I surfed this forum and it helped me a lot. Know I am at a point to begin coding my enine, but there is one crucial question:

      Am I allowed to use code like this in a Node's ActionHandler:

      public void execute(ExecutionContext executionContext) throws Exception {
      
       this.jbpmContext = executionContext.getJbpmContext();
       jbpmContext.getSession().beginTransaction();
       try {
       doSth();
       } catch (MdcInstanceExistsExcepiton e) {
       handleSth{}
       }
      
       jbpmContext.save(executionContext.getProcessInstance());
       jbpmContext.getSession().getTransaction().commit();
      
       executionContext.getNode().leave(executionContext);
      
       }
      


      My Comments:

      1 I KNOW that you do not advise to save sth. in an actionhandler, but we have here some
      situations where I have to guarantee that data is really written to the database.

      3 I have seen that similar methods in JbpmSession are deprecated. Why?

      2 This code works fine within my tests.

      My question:

      Does this approach actually break anything of the inner workflow of the surrounding jbpmContext?

      By the way: Is there a tool out there, that shows me the actual state of all processes? Sth. like
      a "JBPM shell" or "JBPM Webmin"? I only know about the StartersKit webapp...

      Best Regards & any help is greatfully appreciated!!

      Harry


        • 1. Re: Accessing the underlaying hibernate session / transactio
          Koen Aers Master

          Harry,

          Committing a transaction inside an action handler like you do is not always bad. The only thing that you should be aware of is that from a client perspective, you have now really two transactions. The first transaction will do the business behaviour of your node, the second will move the token out of the node and continue the graph execution. So you should take care of the situation where the first transaction succeeds and the second transaction fails yourself.

          Regards,
          Koen