On 8/1/11 22:12 , Falko Bräutigam wrote:
- The store and some concerns need to use weak/soft references too. Ok did it.
Why does the store need it? It should only be the UoW holding references, in the normal case (e.g. Neo4j is different, as it uses transactions as well).
- If the store uses soft references, then it needs a way to get notified if an entity has been modified, so that it can make a strong reference to it (in order to not loose modified state). Currently I dont see a way to let the store know (without introducing a new method). - My simple approach introduces a race condition that may lead to lost update in the worst case. Situation: A reads entity and presents it in the UI. Then GC reclaims the entity. Then B reads/modifies/commits this entity. Then A reads the entity again (together with new timestamp from B), modifies something that B has modified and writes back to the store loosing changes from B.
This is quite easily solved by using a REST API that uses timestamps and 409 status properly. I did this in Streamflow, and it avoids those kinds of race conditions.
- Is an UoW supposed to be accessed by concurrent threads? If yes then check/set entities from cache code in UnitOfWorkInstance needs to be synchronized with the cache.
UoW is for one thread only.
Any ideas? And/or are there any other problems/pitfalls I'm missing so far?
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.
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.
/Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
