Re: [jbpm-dev] Help with ht problem? (Re: BZ 853019)

Hi Maciej, Just so were on the same page, (and for clarification to others reading along), this is what we're talking about (I think :) ): 1. Changing the TaskServiceSession so that instantiation starts a transaction and disposal ends the transaction. (Currently, tx's in human-task are started at various different points depending on the operation requested). 2. Changing the LocalTaskService so that a TaskServiceSession is instantiated and disposed with every operation. The main reason to do 2 is because otherwise, programs that are already written that use the LocalTaskService might break. At this point, users currently using the LocalTaskService expect that the transaction (whether it's a local or JTA tx) will be ended by the LocalTaskService at the end of an operation. If we only do 1 (change tx behaviour) but not 2, then a tx will be opened when the LocalTaskService is initiated and a tx will only be closed when the LocalTaskService is closed. (All the tx logic inbetween will not fire, because the tx mgr will see that there's an active tx and not do anything to modify the status of the active tx.). Except, for JTA tx's -- and probably also for Spring tx's -- this isn't true. Something else that the user is doing could then end those tx's, and that would break the LocalTaskService instance (which expects to be able to close a tx when it disposes -- but can't, because the user already has. ) True, in this situation everything would work (because of the inner tx logic) until the LocalTaskService was disposed. Besides the technical consideration above, there's also the fact that users now expect the behaviour of the LocalTaskService to be transactional. That means that if they're using the LocalTaskService, and an exception is thrown halfway through, that the things that have been already done using the LocalTaskService will .. well, be done. If we don't do 2 (ensure similar tx behaviour), then the following situation can occur, and users will definitely be angry about this: 1. User initializes LocalTaskService 2. User starts process (where by 5 tasks are created). 3. User completes task 1 (of 5) via LocalTaskService 4. User completes task 2 (of 5) via LocalTaskService 5. Exception is thrown by something, and we exit the stack. If we don't do ensure similar tx behavior, then a. none of the 5 tasks will have been saved and b. 2 of the 5 tasks (which won't even exist) won't have the status "Completed". -------------------- On another note, I'm realizing that what I'm proposing above is not something we can do anyways. The problem, of course, comes back to the fact that the API/DTO object is our entity. That means that if we go through with the 1,2 (tx by init/dispose and new TaskServiceSession per op), then we can have the following: 1. LocalTaskService initiated, etc.. 2. User calls LocalTaskService and gets a Task object back. - which means: a. entitymanager opened, b. tx opened, c. retrieve task d. tx closed e. em closed. 3. User does something else with LocalTaskService - which means.. (see above) 4. User tries to access something in the Task object -- but something in a (lazily-loaded) collection that of course hasn't been loaded yet. 5. Proxy instance of collection element tries to retrieve the element using the em.. that was closed in 2e. 6. "Boom!" as they say, or in other words, exception and User doesn't understand wtf is going on. So it looks like we're back to my original Option 2 or 3: 2. Run through option tree in order to force loading 3. tx around session.write(). I'm favoring option 3, mostly because it's the least work and probably the most robust. Obviously, neither option involves changing the LocalTaskService. Thanks, Marco 13-09-12 09:15, Maciej Swiderski: -- jBPM/Drools developer Utrecht, the Netherlands