On Fri, Nov 20, 2009 at 8:20 AM, Rickard Öberg <[email protected]> wrote: > On 2009-11-20 14.58, Niclas Hedhman wrote: >>> >>> The thing is that Johan wanted to experiment with having the UoW backed >>> directly by a tx. >> >> it has obviously been a long time since we came up with UnitOfWork, >> that it can be suspended and resumed as well as nested variant. >> Looking at the code now, I am not totally sure how it was supposed to >> work (perhaps since the dynamic Visibility issue has been resolved on >> top of the original work). >> I also recall that you said that nested uow doesn't work and need to >> be revisited, and I wonder if it is related to that we are not clear >> on what the semantics really are. > > Nested UoW code needs to be cleaned up, yes, but the semantics I think are > reasonably clear. If you do something in a top UoW and then create a nested > UoW, then the nested UoW should see the modified state from the parent, > along with "fresh" state from the EntityStore if it has not been > loaded/modified in the parent UoW. > > But whether this is enough, or whether nested UoW's are simply overkill, is > another matter. At this point I'm not sure.
As pointed out the goal with the current implementation is to test if it is possible to map UoW directly towards a Neo4j transaction. The problem now is that running multiple (top level) UoW concurrently in the same thread using suspend/resume will deadlock once they start to modify the same entities (running in different threads will either complete or throw a deadlock detected exception). UoW (versions + concurrent modification) is quite different from Neo4j transactions (write locks + deadlock detection). The loss of having a load/store pattern only opening up the transaction during apply is big (code complexity, performance, memory usage etc) so I still hope the current implementation can be used (maybe with some specific constraints when using Qi4j+Neo4j?). If it does not work out we have to rewrite it using load/store or wait and see how the planned "Neo4j native store with versions" spike plays out. If we manage to implement a Neo4j native store with versions UoW will map much better towards it (no write locks and the store throws ConcurrentModifcationException). Regards, -Johan _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
