Niclas Hedhman wrote:
Hmmm....??? I am skeptical... mostly since I don't think that real
cases are this neat and can be easily understood. I am more concerned
over 'cause and effect'. Setting x->3 above could very well be due to
the fact that y="Foo". How is that handled?
That depends entirely on the usecase I think. If the usecase is such
that a concurrent exception requires the whole UoW to be discarded and
done all over, then that is fine. If the usecase is such that a
concurrent exception should cause a refresh() and then the user can
review the changes before completing again, that is also fine. And, if
the usecase is such that the refresh()/complete() can be done without
human intervention in between, that is also a possibility. So, all
levels are possible here.
Then it is nothing related
to merge, but running through the code again (unless the mutation code
are small objects that are put into the UoW, as discussed previously).
All changes are events, so it's simply a matter of re-running the events.
And since we need to support that, the 'merge' case is barely needed.
Providing the 'merge' facility may even cause more damage to our
reputation, since it might be overused and causing inconsistencies all
over the place (esp if run 'automated' without user interactions),
easily blamed on a 'flawed Qi4j model'.
But, what you describe is the first case I outlined: on
ConcurrentException, discard the UoW and do it all again. Just like how
transactions work. But, IF possible the user can choose to simply do
refresh(), review the new state, and then complete() again. Or, simply
do a refresh() and complete() automatically. This all depends on the
specific usecase I think. But all are possible, and useful.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
