[TransWarp] Windows, LDAP, and transactions

[Roché Compaan]

On Mon, 30 Dec 2002 16:16:14 -0500
"Phillip J. Eby" <pje at telecommunity.com> wrote:

> At 03:50 PM 12/30/02 -0500, Phillip J. Eby wrote:
> >At 03:32 PM 12/30/02 +0200, Roché Compaan wrote:
> >>But an EntityDM wants to join a transaction in __getitem__ so how will
> >>they work with a LDAPConnection?
> >
> >They'll work just fine.  LDAPConnection objects just aren't going to be 
> >transactional.  I'll probably give them modification methods (e.g. add, 
> >change, delete) that require autocommit to be engaged.  Thus, you won't be 
> >able to use an LDAP connection for modification operations unless you give 
> >it a transaction of its own and engage its autocommit flag.  The result 
> >will be that you'll be forced to acknowledge the non-transactionality of 
> >LDAP in order to perform modifications with it.
> 
> Just to clarify the above a bit...  keep in mind that the EntityDM and the 
> LDAPConnection don't have to be part of the same transaction.  Also, just 
> because the DM has joined a transaction, doesn't mean the LDAP connection 
> has to.  If you want to have a DM that wants to be able to *write* to an 
> LDAP connection, your job is going to be a bit more complex.  You'll need 
> to have the save() method put items in some kind of modification queue, to 
> be executed in the voting phase of the DM's transaction.  Ideally, you'd do 
> this in a way that ensured that the LDAP write operation took place as the 
> very first real database write in the whole transaction, and that there was 
> only one LDAP write operation per transaction.  That would be the only way 
> to do it safely, I believe.

There's one problem: the LDAP write operation might succeed and
subsequent writes by other DMs to other storage devices in the same
transaction might fail.

> Of course, if you can also guarantee that no other "real" writes to storage 
> devices (files, databases, etc.) are taking place in the same transaction, 
> then you can bypass all of this stuff.  Just go ahead and do the LDAP write 
> in the DM's save() method.  If it succeeds, great.  If it fails, you get an 
> error and tell the user.  So, if your use cases for LDAP modification can 
> be fit into that pattern, you're all set.

This seems like the *only* safe way and I think one should seriously
consider this when you design your app.

-- 
Roché Compaan
Upfront Systems                 http://www.upfrontsystems.co.za