[TransWarp] Windows, LDAP, and transactions

[Phillip J. Eby]

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.

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.

The thing is, though, if your LDAP modification use cases *don't* fit that 
pattern, you're probably in for a rough ride anyway...  LDAP directories 
aren't "real" databases.