Best options for implementing my own Transaction provider

Question

I'm using a remote 3rd party storage solution that does not have support for transactions.

I want to implement my own pseudo-ACIDity in .NET for this solution by simply attempting to rewrite/delete non-failing Entity inserts/update to get to an old-data-but-good-data state when other inserts/updates fail inside a transaction context.

Is it beneficial or easier to integrate with System.Transactions namespace somehow (anybody have horror or success stories on this? Is it compatible with the general idea of what I am trying to do?) or should I create my own Transaction classes and interfaces?

Edit: I found Implementing a Resource Manager on MSDN for integrating with System.Transactions, is this the way to go? Or should I just model a custom one on this pattern?

Edit: Reading Hibernate's docs, that is exactly the pattern I will utltimately want. Should I just download NHibernate and trim out all the SQL code or use its base classes and interfaces and implement my custom CRUD code or is it very SQL dependent? I've found myself already almost rewriting some of my methods to conform to its documentation.

Answer 1

;-) I was just adding that very link when I saw your edit.

I would probably explore that option first. Whenever there's an extensible framework available, you should hesitate to build one yourself.

Answer 2

You should implement a resource manager, yes. Getting System.Transaction support is no small thing. It will allow your devs to, for example, commit updates to your resource as well as to Oracle, in the same unit of work. You get that for free if you build your library so that it is a resource manager.