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.
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.
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.
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.
Sure, I'm all for that. I just need to understand what level you are
aiming at, and if what you're aiming for is possible.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
