Welcome to MSDN Blogs Sign in | Join | Help

Transactions and in-memory data (part 3 of n)

Last time I laid out a little framework for transactional rollback.  It clearly is not sufficient for a real honest-to-goodness persistent transaction but if you can tolerate every ESE failing (due to allocating the rollback log entry) it's pretty compelling.  Pretty much every function can be transactional if it only works with data structures/algorithms which could support this metaphor.  It might look something like...

int do_work(collection_t *collection, int x, int y, int z) {
   rollback_record_t *txn = NULL;
   int err;
   if ((err = collection_insert(&txn, collection, x))) {
      do_rollback(txn);
      return err;
   }
   if ((err = collection_remove(&txn, collection, y))) {
      do_rollback(txn);
      return err;
   }
   if ((err = collection_do_something_else(&txn, collection, z))) {
      do_rollback(txn);
      return err;
   }
   free_rollback(txn);
   return 0;
}

Hey, that's kinda cool.  Pretty easy to write a transactional function, eh?  But wait there's more.  With this metaphor it's also easy to be a good transactional citizen!

int do_work(rollback_record_t **parent_txn, collection_t *collection, int x, int y, int z) {
   rollback_record_t *txn = NULL;
   int err;
   if ((err = collection_insert(&txn, collection, x))) {
      do_rollback(txn);
      return err;
   }
   if ((err = collection_remove(&txn, collection, y))) {
      do_rollback(txn);
      return err;
   }
   if ((err = collection_do_something_else(&txn, collection, z))) {
      do_rollback(txn);
      return err;
   }
   merge_rollback(txn, parent_txn);
   return 0;
}

Hey, woah maybe we're on to something!

Hmm.. it's going to be hard to use other libraries... what if I don't really need this level of guarantee?  What if people point at the code and say it's weird?  I guess social acceptability is as important as reliability and correctness...

 

Published Wednesday, May 18, 2005 12:24 AM by mgrier

Comments

# re: Transactions and in-memory data (part 3 of n)

Wednesday, May 18, 2005 2:10 AM by indranilbanerjee
A few general points

do_rollback() and merge_rollback() must be guaranteed not to fail, right?

It would be impossibly hard to included 3rd party libraries in a transaction scheme that they are unaware of.

This scheme would work in an single threaded world, but in MT you have to start worrying about isolation levels. Do you want other thread to see the state of your collection before it has been commited.

The Java Transaction API JTA address these issues http://java.sun.com/j2ee/transactions/index.jsp

# re: Transactions and in-memory data (part 3 of n)

Wednesday, May 18, 2005 2:50 AM by Anonymous
So does Indigo... (As well as the COM+ predecessor)
New Comments to this post are disabled
 
Page view tracker