[TransWarp] Windows, LDAP, and transactions
Phillip J. Eby
pje at telecommunity.com
Mon Dec 30 16:16:14 EST 2002
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.
More information about the PEAK