Hey, There is something very weird with UnitOfWork and type lookups as it is today. Example: In Module A there are no Entities registered. A Service X in Module A creates a UnitOfWork and calls another Service Y in Module B, where Entity XYZ is registered. The second Service Y wants to do a lookup of Entity XYZ with id 123 and return it to the first service X. But if he simply does UOWF.currentUnitOfWork(), then it will not be able to find XYZ since it is associated with Module A. Y must therefore create a nestedUnitOfWork from currentUnitOfWork, then lookup 123, and then *pause* the nestedUnitOfWork and return 123 to Service X. 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. 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. This way only one logical UoW has to be created, and it would be more similar to at least my mental understanding of what a UoW is. Does this make sense? WDYT? /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
