[jboss-user] [JBoss jBPM] - Re: jBPM 3.1 beta 2 is not thread safe !

jonabbey do-not-reply at jboss.com
Mon Aug 28 19:02:38 EDT 2006


"jonabbey" wrote : "kukeltje" wrote : "jonabbey" wrote : 
  |   |   | It appears that the problem is that the JbpmConfiguration class uses ThreadLocalStorage for the jbpmContextStacks.. If we attempt to hold a context open and call it from multiple threads, we'll see this error.
  |   |   | 
  |   | afaik, you are not supposed to keep them open
  | 
  | I thought jbpmContext was used to mark the transaction boundary?  If we can't keep a jbpmContext open long enough to make multiple calls on it, how do we ensure that the operations are done (or not done) in a single transaction?
  | 
  | 

Besides, if we want to allow an RMI client to make multiple calls to the server, (even ones that would naturally flow in a single thread sequence in the absence of RMI), RMI *will* spread those calls out on the server over multiple threads.  That makes the API rather unusuable, as we'd have to define  a separate RMI method for each permuted collection of API calls that we'd want to make between a createContext() call and a close() call.  

We'd like to be able to have our RMI client make calls to multiple objects on the server in the same sort of natural way that you'd do in a single thread on the server, but we can't guarantee that two successive calls will execute on the same thread.

At least, not without doing what we're doing to get around this.  We're creating a worker thread and forcing all RMI calls for a session to dispatch through this thread, similar to how the SwingUtils.invokeLater() method works.

It would be nice to have a bit more guidance as to how this API is intended to be used, though.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3967965#3967965

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3967965



More information about the jboss-user mailing list