Re: backend requirements for syncrepl

["Pierangelo Masarati" <ando@sys-net.it>]

>> >For CSN, you can construct something from any timestamp.
>> >
>> this should not be an issue.
>
> Currently, a new entryCSN value is obtained and sent when entry is
> returned
> by back-sql. Although it can be constructed dynamically from any
> timestamp,
> the entryCSN for an entry should be derived from a static timestamp in the
> database. Otherwise, synchronization session will always perform a full
> reload.

That's my intention.  I plan to work in two directions:
1) provide a modification timestamp in the ldap_entries table, updated by
triggers (high level of cooperation between the RDBMS and back-sql)
2) always perform a full reload (no cooperation between the RDBMS and
back-sql).

The latter is likely to be a typical scenario for most implementations,
where no-one notifies changes nor even update the ldap_entries table,
which, in fact, is more likely to be implemented as a view.

Note that a medium level of cooperation is provided by triggers or agents
that update table ldap_entries when new entries are created/deleted; this
should be easy because entry creation/deletion is roughly univocal in
back-sql's design (e.g. a specific key in a specific table must exist);
modifications are much more subtle, because they can occur anywhere in the
database without even being related to the main table, so a trigger/agent
that updates the timestamp may even be impossible or non convenient.

The scenario (2) is very realistic, although non-optimal.  Of course
reloads need to be scheduled within a reasonable time distance, to relieve
both provider and consumer from excessive workload, and tuned on the
actual size of the db.

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497