Re: faked transactions

[M Butcher <mbutcher@grcomputing.net>]

I may be missing something obvious, but if you didn't run slurpd as a
daemon, and instead ran it in oneshot mode after an update is complete,
that would be sort of like transaction support. It's outside of the LDAP
APIs, and requires starting the slurpd process from the command line,
shell script, etc... but I think it could accomplish what you are after.

Matt 


On Tue, 2003-05-13 at 13:23, Nahuel Greco wrote:
> Hi, i'm trying to setup an OpenLDAP configuration that mimicks transactional
> behavior.
>  
> I have the following scenario: one LDAP client ("administrator") modifying
> an LDAP directory, and multiple LDAP clients ("users") reading from it. The
> problem is how to configure OpenLDAP to make the administrator updates
> atomic, that is, the administrator (remember, he is only one) can make
> any type and quantity of changes to the LDAP directory, but the users
> must only see the LDAP directory as it was before the administrator
> changes, or as it become after them, but _never_ in a middle state. 
> 
> I have been crawling the web and found a draft to add transactions
> to the LDAP protocol, but OpenLDAP doesn't appears to implement it 
> (it was a possible solution because I can make any changes to the
> administrator LDAP programs). So, I'm thinking to fake them, one
> possible configuration is:
> 
>    administrator ---> LDAP Master server
>                            |
>                            | "atomic synchronization" 
>                            |
>                       LDAP Slave server  <---- clients
> 
> So, the problem is reduced on how to do that "atomic synchronization",
> I haven't found an 'standard' way in OpenLDAP to do that (correct me
> if i'm wrong), only a ietf draft (requeriment 6.13 in
> draft-weiser-replica-req-01.txt) that isn't implemented (isn't it?).
> 
> There is a way to stop the LDAP Slave server resuming the client's
> searches but without closing the connections to them, and then
> make it retrieve the update from the Master and resume their operations
> restarting in a transparent way to the clients?
> 
> Note, because the volume of my directory, and the fact that the
> master and slave server will run in the same physical machine but
> in different ports, is also possible to make the "synchronization"
> copying the database files from the master to the slave, but the
> problem of stoping the slave without breaking the connections to
> the clients persists.
> 
> Also, I see in latest OpenLDAP server that transaction support is
> in the to-do list. What is the difficult level of implementing them
> (I might help but i'm not familiarized with the OpenLDAP codebase). 
> 
> Well, any ideas? :) 
> 
> Saludos,
> 
> Nahuel Greco.
-- 
M Butcher <mbutcher@grcomputing.net>