Great. I'd rather go to merging the EntityState in complete.
Those not completing UoW would then have no effect in the parent UoW. Unlike now ? Michael Am 06.03.2009 2:50 Uhr, schrieb Rickard Öberg: > Hey, > > I'm in the process of implementing the changes to UoW that I mentioned > yesterday. Basically, when you do UoWF.currentUnitOfWork() that will > return a UoW implementation that is adapted to the Module of the caller, > so there's no longer any need to do nestedUnitOfWork() just to get > correct visibility. This is GOODNESS! > > BUT, one implementation detail I'm stumbling on is this scenario: > A base UoW is created in a Module that sees NO Entities whatever. > A call is made to a Service in a Module which *does* see Entities. The > service does UoW.nestedUnitOfWork() and does find() on an Entity. The > Service works on the Entity, completes the nestedUnitOfWork() and then > returns. The outer code then does UoW.complete(). Again, note that the > calling code doesn't "see" the Entity, from a Module visibility point of > view. > > Question: > When the Service finds() the Entity, should the EntityState be > force-loaded into the parent UoW? Meaning, if another nested UoW loads > the same Entity it will see the state of it as it was when it was > find()'ed the first time. Or, should the state only be loaded into the > nested UoW and ONLY upon complete() is it merged back into the parent > UoW so that the parent and other nested UoW's can see it? > > Right now it is force-loaded, but I'm leaning towards skipping that... > > /Rickard > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev -- Michael Hunger Independent Consultant Web: http://www.jexp.de Email: [email protected] Enthusiastic Evangelist for Better Software Development Don't stop where you are: http://creating.passionate-developers.org We support Software Engineering Radio (www.se-radio.net) _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
