On Sat, Oct 2, 2010 at 11:42 AM, Rickard Öberg <[email protected]> wrote: > On 2010-10-02 11.28, Niclas Hedhman wrote: >> >> 1. UnitOfWork already has a state and instance cache as a HashMap. >> Although the logic is slightly different from what I describe, it felt >> natural to plugin to the same concepts. > > Wait, are you going to plugin the cache in UoW? Not EntityStore?
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. >> 2. Providing "clone-on-modify" to reduce caching space needed when a >> lot of read-only entities are being requested. > > If you want to make clone-on-modify (which makes since given read-mostly > apps), then it seems most natural to make a custom EntityState that does the > clone on set-methods. 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. You also need clone-on-remove, but that is minor... I have not even noticed that a JSONEntityState is now 'default', and I have not checked what its relationship with DefaultEntityState is, but to me it looks like very expensive implementation (fromJSON() on every call), and from that perspective I guess EntityComposite creation is quite cheap and entity instance caching might not be relevant. But I don't think we should aim for a sub-optimal solution and instead aim for the high throughput and smallest footprint possible, while we are at it. 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
