I'd like to write an ADO.NET provider for a non-relational data
store.  I'd like to make it support transactions, but since it's a
third party tool I'm using to store and retrieve data, and it doesn't
'support transactions' I'd like to know just what exactly that means.
I mean, how do I implement an interface layer that does support
transactions, and what is required?  Is this 'transaction support'
simply meaning that it has to have some interface to the pre-built
(D)Com Style Distributed Transaction Coordinator, or what?  If I were
to go about making something that were to 'support transactions' (as
everyone says as if there is not a way to actually make something that
does so that already does not).  Do I have to do some native Code for
Com, do I have to register something somewhere? What interface do I
have to implement?  I certainly hope it doesn't just mean 'you must
use SQL, Access, DB2, or Oracle' or something like that, because then
that sure as heck closes a lot of doors.  Believe it or not there are
better ways to store data than the relational model for many
applications.  So, what's up? Can anyone enlighten me about this?
What exactly does it mean (not at a high level, but under the covers)
when one says that I must be dealing with a datastore that 'supports
transactions' in order to use System.Transactions namespace?

--dave

VISTA and installing .NET 1.1
Learning & Frustration.
Most popular object persistence framework
Programmatic diagnostic questions about dlls
Is This Overkill?