On 8/2/11 17:02 , Falko Bräutigam wrote:
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.
Not sure what you mean. The EntityStates hold timestamps for last time they were modified, persistently. When *loading* if that timestamp is after the UoW was started, then we know the UoW should fail. So, if you think about a UoW that "takes a very long time", and where unmodified entities are dropped on suspend()/resume(), then this will ensure that even though entities may be reloaded from disk, they have not changed *for the duration of the UoW*. That is what you need, right?
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?
You're right, if SoftReferences are used, instead of explicit suspend/resume, to do the dropping, there would be no difference. The timestamps in the entities and the UoW ensures that everything is fine anyway. Problem is that SoftReferences don't work as advertised.
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?
Before anything else, stop thinking of using GC to purge entities. SoftReferences are deadly and WILL bite you...
/Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
