On Thu, Mar 5, 2009 at 7:37 PM, Rickard Öberg <[email protected]> wrote: > There is something very weird with UnitOfWork and type lookups as it is > today.
> The nested UoW will never be completed. > > This whole thing is just bizarre, and stems from the fact that the UoW > is strongly associated with the module it was created in. But this > causes strange usage of nestedUnitOfWork, which I think somehow is wrong. Yes, I agree that a non-completed nested UoW is a sign of something terribly wrong. > Here's a solution which might fix it: > UnitOfWork is internally divided into two parts: the cache of state and > a thin wrapper holding the cache and a ModuleInstance. When you call > UoWF.newUnitOfWork() it creates a new cache and returns a wrapper to it > for the client to use. BUT, when you later call UoWF.currentUnitOfWork() > it finds the current UoW on the thread stack, but only the cache, and > then creates a new wrapper with the ModuleInstance of the caller. This > way client code can start the UoW, but they can't "see" the Entity > composites. When they then call Services, which get ahold of the current > UoW, they can create/find Entities which the client cannot see, since > their version of the UoW is bound to their module, where the Entities > are visible. So, the currentUnitOfWork() method will actually return a different proxy for each user, and that the proxy resolves the visibility but the state goes to the actual UoW. Ok, that can work (provided people don't start passing UoW's around). And the EntityStore implementation of the UoW doesn't care, hence goes straight into state, and therefor nested UoW would work too... I am pretty sure that there are other solutions, but since I heard that you have practically implemented this already, I say let's go for it and see how it turns out. There are quite a few testcases waiting for http://issues.ops4j.org/browse/QI-147 to be solved. Cheers Niclas -- http://www.qi4j.org - New Energy for Java _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
