On 8/3/11 18:22 , Falko Bräutigam wrote:
Yes, this is exactly my problem. I need to support this merge scenario
but don't see how to do. Once the Uow is "invalid" (concurrent
modification exception) I don't see a way to "cure" this using the
current API/SPI of Qi4j.
The usecase I described above is valid, I think. Probably any system
that deals with concurrent modifications using optimistic locks needs a)
a way to detect concurrent modifications and b) a way to "merge"
concurrent modifications. Where b) is domain specific and thus needs to
be done by the user, so an exposed API is needed to let the programmer
give the user a proper UI to do it.
There are two cases. One is where two literally concurrent transactions
perform updates that clash. For that you can simply roll back the
slowest, and try again. In Streamflow I retry 10 times before giving up.
The second case is where you have think-time, and where the concurrency
check will always fail, simply because someone else has changed it from
before. What I do is to notify the user, and refresh the state so that
the action can be performed again, if necessary.
Any attemps at "smarter" merges would in many cases be quite dangerous.
It cannot be generic.
Hmmm... in Qi4J to support b) I could open a new UoW and transfer
entities (together with my "merged" modifications). Is this possible
using UnitOfWork.get(T) ?
You could do that, but it's a bit dangerous I think. Isn't it better to
simply roll back the whole thing and let the user do it again? How often
does it occur?
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
