On Sat, Oct 2, 2010 at 1:25 PM, Rickard Öberg <[email protected]> wrote: > On 2010-10-02 13.10, Niclas Hedhman wrote: >> >> I think it makes more sense to do it in UoW level. It gives the most >> efficiency in terms of memory footprint and room for improvements >> (entity instance caching) beyond that of what is possible at ES level. > > What exactly are you going to cache? The EntityInstance? That wouldn't even > be close to workable I think, since it is tied to a particular UoW.
Ok, I have had a deeper look, and you might be right. The bound UnitOfWork will be needed during creation of new entities or retrieval of associations. Side note; since we don't support entities to cross threads, why do we need the ModuleUnitOfWork per entity instance, and not pick it up from ModuleInstance.uowf.currentUow() ?? Memory savings might not be great, but still... >>> If you start with the JSONEntityState it's basically >>> an if-not-cloned-then-clone clause before doing the set, and that should >>> be all. > Note that the calls to the method will be cached in the > EntityPropertyInstance, i.e. if you access the same property twice, it is > only deserialized from JSON once. In which case "that should be all" isn't true, since that cached value need to be invalidated. The EntityState seems to be passed out and held in quite a lot of places, which basically disqualify it from being cached at that level. And since EntityState also holds the version, lastModified and status (and we can't reach the places where it is used) we can't cache EntityState either in a "global read-only, clone on write" cache. And leaving us with a "always clone from global cache", seems a bit petty in comparison. Changing that at UoW level is non-trivial, and although I suspect we would end up with a cleaner UoW implementation in general, I don't think now is the time for it. Ok, assuming that, the other alternative that I was sketching on is basically to push the problem to the EntityStore implementations' get/apply logic, where get() checks the cache, if found read it, if not read the underlying store, and invalidate/update on apply(). Perhaps that scope is more reasonable considering the time available... Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
