Am Tuesday 19 January 2010 05:39:30 schrieb Bob Walters:
On Mon, Jan 18, 2010 at 4:02 PM, Stefan Strasser <strasser@uni-bremen.de> wrote:
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
How do you control atomicity with this design? i.e. If a transaction modifies A and B and you are using a lock-free approach to update the cached versions of these objects from their shadow copies, how do you ensure that any other threads which might be reading A and B (or B and A) see the two entries consistently?
that's part of the optimistic approach, a transaction is allowed to see an inconsistent (inter-object) state, but it is guaranteed to fail with an isolation_exception, at commit at the latest, if it did. (there were also pessimistic transactions once, but they fell victim to some refactoring...)
I'm not against throwing away portions of my code base to better unify.
I'm neither. could you point me to your free list/allocation code? my library spends a lot of time allocating and deallocating disk space, I guess there could be improvements. my logger is already pretty generic (because I planned to use it for the storage engine log and for the log of the transaction manager for distributed transaction). here's some example code on how to use it: typedef mpl::vector< map_inserted, //must be POD map_entry_removed, ...,
entries;
olog<entries> myolog(...); myolog << map_inserted(1,2,3); myolog << map_entry_removed(4,5); --- struct listener{ void operator()(map_inserted){ } void operator()(map_entry_removed){ } }; ilog<entries> myilog(...); myilog >> listener(); hidden behind olog is all the log rolling and the syncing interval stuff we've discussed to ensure sequential writing performance.