[TransWarp] Windows, LDAP, and transactions

[Phillip J. Eby]

At 11:36 AM 12/31/02 +0200, Roché Compaan wrote:
>On Mon, 30 Dec 2002 16:16:14 -0500
>"Phillip J. Eby" <pje at telecommunity.com> wrote:
> > 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.

Yep.  Which is why you want to keep that operation queue around so you can 
at least attempt to back it out.  I forgot to mention that part.  PEAK 
transactions can also have special error handlers to take care of various 
sorts of "hosed" transaction states, where a DM fails after it swore up and 
down it could commit.  Probably the simpler thing in this case would 
actually be to have the write operation take place in the "commit" phase 
rather than the "vote" phase, and then you can at least log the incorrectly 
completed LDAP operation.  But of course, these are really all last-resort 
techniques anyway.  Better to design your LDAP directory so that you never 
need to change more than one record in it at a time, and never in 
conjunction with other operations that must be atomic.

The (relatively) simple workaround in most cases is to make your master 
storage be in a "real database", and then either have a process that 
synchronizes the main directory, or else use a directory server (like 
OpenLDAP) that supports custom back-ends.


> > 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.

Right.  As I said, if this *isn't* your use case for LDAP, you're in for a 
fairly rough ride no matter what tool you use.