Niclas Hedhman wrote:
I say that you have probably forgotten why it was the way it was...
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.
I am not sure that "Not many stores support it today" is an accurate
statement. AFAICT, JDBM does, and your REST does not. I think Neo
does, and my Swift is supposed to do it. Going from supporting our
structure to JTA is a *huge* step, and not sure I like it at all.
>
When we start getting the hang of Aggregates, the conclusion might be
that Aggregates are not allowed to be spread across EntityStores, but
I am still worried over a simple case;
Aggregates definitely should not be spread across EntityStores. That
seems to be one of the major conclusion from all the discussions about
Aggregates and persistence that I've seen so far.
* Take an Entity from ES1.
* Store the Entity in ES2.
AFAICT this can only be done with the new casting support. Is this what
you're thinking about?
But I see your point. Hm...
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
