Am Monday 18 January 2010 19:27:25 schrieb Oliver Kowalke:
I would suggest a three phase model for transactions operating on shared resource:
1.) prepare phase: multiple readers/one writer have access to the resource 2.) modification phase: only one writer has access and can can modify the resource 3.) commit/rollback phase: write publishes its local modifications and releases the execlusive lock
With this pattern you cold support queries and transactions in parrallel (at least for phase 1 and 3).
I would leave this up to the resources. the resource only has to make sure that the state that was the basis for signalling a successful prepare-phase in a two-phase-commit is upheld until commit: prepare: returns if the transaction can be committed. commit: publish the local modifications. if prepare signalled a successful transaction, this has to succeed. an exclusive lock to the entire resource could be used to upheld the state of the prepare phase until commit, but there are other ways. my implementation e.g. never blocks another transaction from reading an object, even during commit, based on http://en.wikipedia.org/wiki/Optimistic_concurrency_control and http://en.wikipedia.org/wiki/Multiversion_concurrency_control Bob(STLdb) is more concerned about unnessary rollbacks because he expects a higher rate of concurrent access in indexes, so locks are even acquired in your "phase 1" and are upheld until commit. both approaches might be right for their specific use case.