1 Reply Latest reply on Feb 27, 2006 11:57 AM by kukeltje

    JMS async continuations

    edgarpoce

      hi,

      I had problems running the async stuff with JMS. When I try to run the command that comes in the message I get a lazy initialization exception because the hibernate session was closed. I think that it's because the command wasn't loaded with hibernate, it was serialized with jms. I solved it by creating a new command instance in my JMS command executor[1]. But it is not safe because the token might be in another node, maybe the Command interface should include a new method, e.g. (void execute(JbpmContext context)) that reloads the command fields and executes the command with the given context, has it any sense?.

      And it seems JmsMessageServiceImpl delivers the messages before the process is saved, it causes the message consumer to try to execute the commands on a process which is not saved yet. Any idea of how to do a workaround for this?

      Any help will be highly appreciated.

      [1]


      /**
      * {@inheritdoc}
      */
      public void onMessage(Message msg) {
      try {
      long tokenId = msg.getLongProperty("tokenId");
      JbpmContext jbpmContext = jbpmConfiguration.createJbpmContext();
      Token token = jbpmContext.getGraphSession().loadToken(tokenId);
      ExecuteNodeCommand cmd = new ExecuteNodeCommand(token.getNode(),
      token);
      cmd.execute();
      jbpmContext.save(token);
      } catch (Exception e) {
      mdbContext.setRollbackOnly();
      log.error("message '" + msg
      + "' threw exception. rolling back transaction", e);
      }
      }


        • 1. Re: JMS async continuations
          kukeltje

           

          "edgarpoce" wrote:


          I solved it by creating a new command instance in my JMS command executor[1]. But it is not safe because the token might be in another node,


          You mean when the async method returns, the token can be in another node then what it was when the async action was started? Could be if something els e signalled it. Then you will signal it again this way and not get the result you wanted. Reloading it with the context it was created in is imo not right (but I might overlook something. The internals of jBPM are not 100% known to me) Why not
          1: prevent other code from signalling the token or
          2: use additional info (node id or whatever) and check if this is also the same. If not, throw an 'token already signalled' exception or something like that.

          Ronald