Niclas Hedhman wrote: > I am not sure exactly what use-case you are talking about it here. > > But the UoW will act as an EntityStore, which means that; > > 1. childUOW1 reads E1. > 2. childUOW1 reads E2. > 3. childUOW1 modifies E2. > 4. childUOW2 reads E1. > 5. childUOW2 changes E1. > 6. childUOW2 completes > 7. childUOW1 completes <-- ConcurrentModification > > The parent UOW will need to be able to detect step7 and throw a > modification exception. I am not totally sure, but to me that feels > like any "read Entity" inside a nested UoW must be 'loaded' in the > parent UoW, but I am not sure.
The problem is this: the parent UoW has not loaded the Entity. The parent UoW furthermore has NO way to load that Entity, if it had not been loaded by client code, since it has noooo idea what EntityStore it comes from. So, a UoW acts as an EntityStore *only* if the QualifiedIdentity to be loaded actually has been referenced from it, or if it has been merged down into it by another nested UoW. If the parent UoW is empty, then the nested UoW has to use the original EntityStore directly. When the nested UoW completes it can then merge the EntityState down to the parent, and tell the parent what EntityStore it came from. Any nested UoW after that which wants to use the same Entity will then get it from the parent UoW, and the UoW will then act as EntityStore! This is the only way it makes sense I think. /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
