2009/4/16 Rickard Öberg <[email protected]>: > Niclas Hedhman wrote:
>> It was not about JTA transactions at all, AFAIR. It was to support >> that the UoW could use multiple ES, and if any one fails, no change >> would happen to any other. > > But are we then talking about failures on the IO level or on application > level, e.g. one store says "Ok", and another says "Concurrent modification" > and then both aborts? What is it that we want to support? Because if it is > transactionality, then JTA is the way to go. No need to invent that wheel > again. For application level errors that would be more realistic. It could be I/O failure, but more importantly is the ConcurrentModification failure as it is in some cases a lot more common. Now, JTA is not easy to implement, since it has cross-cutting concerns with UnitOfWork, and to ensure that all that works, sounds like a major headache to me, and not a matter of "invent that wheel again". Supporting 2-phase completion in UoW sounds like a simple case, vs the JTA spec implementation, SINCE IFF we say "use JTA" people will use it according to the client spec and not the strict subset we control in UoW. So, I am fine that Aggregates have to be on single ES, but if we don't have JTA and not 2-phase integrity in UoW, then I think the system is too weak for a large portion of users, and that it will be difficult to defend. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
