At pub, so don't assume I got all this right; In version 1.3(?) we abstracted the caching into Extensions. However, IIRC it doesn't deal with the UoW isolation that is needed.
WAY back (0.1?), we had a read-only cache 'under' the UoW to support these kind of issues. Can't recall why it became a problem? On Dec 14, 2011 6:26 PM, "Falko Bräutigam" <[email protected]> wrote: > Hi all, > > thinking a bit more about the "Performance and RAM consumtion" EMail. It > seems that the value cache the PropertyInstance is/has (except for > Collection values) is related. I see 2 functions of this value cache: > > 1. cache deserialized values and make access fast > 2. allow to modify an Entity without modifying the underlying store > > The problem is that this caching behaviour is hardwired and cannot be > switched of. If I got him right this is related to Niclas idea of a > read-only UoW. If 2. would be done somewhere else, then the cache could be > switched off or even better factored out to be a concern that could have > different implementations. > > If the Property value cache could be factored out of the PropertyInstance > implementations, then is would allow for: > > * plugable implementations > * no cache at all > * per Property caching (instead of per Entity) > * sharing of values across Entities > > The last one is half the way to a copy-on-write implementation (that is > able to copy *just* the modified properties instead of the entire entity). > > Does that make any sense? Any ideas? > > -Falko > -- > Falko Bräutigam > http://polymap.org/polymap3 > > ______________________________**_________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/**mailman/listinfo/qi4j-dev<http://lists.ops4j.org/mailman/listinfo/qi4j-dev> > _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
