Rickard Öberg schrieb: [snip]
I think there are many things here. One is that when reading, it should not really be necessary to load entities. I'm looking at extending Query API/SPI so that you can do a query that returns values instead. That being said, for the consistency to be correct, you DO need timestamps for checking upon commit. Again, a REST API that understands this properly fixes it quite easily.
Exactly, for consistency only the timestamps are important, not the entity states. So my current simple approach does this wrong.
One thing we *could* do is to allow entities that have not been modified in a UoW to be purged out of the cache when you do suspend(). I.e. you could load 10000 entities, modify 10, then a suspend()/resume() pair would bring it down to 10 again, and the 9990 entities that were unmodified could be loaded again. Since we now have timestamps on the UoW we could detect if the entities had been changed after the UoW was started, hence triggering a concurrency exception.
Ok, great. But currently the timestamps are held together/inside the entity states, correct? So I would have to change this. Should be easy to let the ConcurrentModificationCheckConcern hold timestamps instead of entire entity states.
With all (latest read) timestamps stored I don't see the difference in concistency between explicit purge on suspend/resume and auto purge by the GC. Does is matter when/why the entity states are purged? It might be a difference for the programmer as entity states may change during lifetime of an UoW if GC is used. But why do you think it is a difference for "lost update" consistency?
In the suspend() all entity states could be checked for their status, ok. But if there would be a way for the UoW to get notified when an entity state changes *and* using a ConcurrentModificationCheckConcern that holds all timestamps, then IMO using the GC to automatically purge entity states would be consistent and very efficient.
What do you think? -Falko -- Falko Bräutigam http://polymap.org/polymap3 _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
