Enough about in-memory models and transactions for now

I want to follow up on this topic of transactional behavior in memory but to motivate it I'm going to have to further discuss my other topics more about invariant restoration and (eventually) failure handling.

The main point is this: there are potentially better ways to solve this overarching problem but there isn't a lot of coherent support for having a set of components which play together well.  You can yourself take on this "transactional" mantra but unless there's deep support for it (possibly integrating with a "real" transactional facility to enable interaction with (rollback/commit of) persistest side effects), you're generally stuck reinventing everything.

I still think it's interesting to take a moment and compare and contrast the reliability of a system which worked in light of transaction support like we've been discussing vs. manual/explicit rollback code.  For extra points, what's the difference between the rollback proposed here and use of C++ destructors.

Comments

• Anonymous
  June 07, 2005
  Do you realize how many times you come up in Google? Especially from your fun loving Digital Days... ;)
• Anonymous
  June 08, 2005
  And yes... That was me.