Hi David, On 25/03/2008, David Jencks <[EMAIL PROTECTED]> wrote: > You appear to want selective bits of the ACID properties of > transactions :-)
Ups.. didn't know that onMessage is a single transaction ;) > It looks like "task" is a persistent status object with some > information about other objects that are actually modified during the > task. Yes, you have deciphered me correctly ;) ObjectMessage holds Task and Task is a persistent object. > To get more processing status visible to clients you need more > transactions, one for each state change that you want to be visible. > I can think of two ways to do this: > > 1. More mdbs: you split the workflow up into more mdbs where each one > updates the status and does some bit of the work, then puts the task > (or task ID) onto a queue for the next one. I'd rather not, I'm afraid of performance issues with chained queues. > 2. A stateless session bean with a RequiresNew method that you call > to update the task with the new status. With this approach you will > probably not want to have the mdb have a copy of the same task object > as the SLSB -- at least I don't know exactly what happens when you > try to send a persistent object across transaction boundaries. I'd > expect trouble. > Hope this gives you hints about a couple ways to proceed the second piece of advice worked! I've created new SLSB with REQUIRES_NEW transaction attribute, also I'm passing id of the task as a parameter, where I simply fetch fresh copy from DB, modify it and update at the end. thanks for hints! best regards Łukasz
