On 2010-10-02 14.03, Niclas Hedhman wrote:
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...
UoW's can be paused, and you still then need access to the UoW for that
particular entity. Example would be configurations.
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.
Nope, it is only valid for that particular UoW, since it is then thrown
away with the UoW.
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.
The EntityState itself cannot be cached, but what it is backed by (e.g.
the JSON object), can be cached. And doing copy-on-write in EntityState
should be easy, since the setters are explicit.
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...
The way I see it there are two options:
1) Cache on MapEntityStore. The Reader might come from cache. This gives
copy on an reads though.
2) Cache in EntityState and coordinate through MapEntityStoreMixin. This
puts caching outside of the underlying MapEntityStore, and provides
possibility for copy-on-write.
If possible, 2) looks very tempting. I have noticed in performance tests
that the JSONObject.read() operations is VERY costly (comparatively), so
getting away from that would be nice.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
