[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: RFC2589 implementation

At 10:24 AM 1/2/2006, Pierangelo Masarati wrote:
>> In regards to replication, I suggest that the master produce
>> replication events for the deletes and the slaves simply
>> act upon these events.  Aside from allowing the use
>> non-dynamic-entry-aware slaves, it prevents replication
>> errors caused by dynamic v. replication event ordering.
>I considered that possibility, but I didn't choose that way because if the
>master crashes the dynamic objects on the slave will never expire. 

Well, you could write them to the DB.

>Another point is that currently when the master shutdowns cleanly, it
>deletes all the dynamic objects; if replica dynamic entry deletion is
>based on replication, dynamic objects would be prematurely deleted on all
>slaves even if only the master was stopped.

If you wrote them to the DB, you could delete them on startup
(if they have expired).  To accomplish this, I'd use absolute
time management internally and just treat the ttl stuff as
the client visable interface.

>I think we can handle this,
>though; but in any case slaves must be able to account for dynamic object
>expiration on their own; or simply, we shouldn't bother too much about
>consistency of replicted dynamic objects.

RFC 2589 was supposedly designed such that no harm would
come from delayed deletion.  Unforunately, the use of
relative TTLs screws this over.  Oh well.

>Ing. Pierangelo Masarati
>Responsabile Open Solution
>OpenLDAP Core Team
>SysNet s.n.c.
>Via Dossi, 8 - 27100 Pavia - ITALIA
>Office:   +39.02.23998309          
>Mobile:   +39.333.4963172
>Email:    pierangelo.masarati@sys-net.it