Alex Karasulu wrote:
Hi there Howard!
On Thu, Feb 3, 2011 at 9:56 PM, Howard Chu<[email protected]> wrote:
Alex Karasulu wrote:
FYI
Hurray! Our respected friends at OpenLDAP are completing the
transaction spec. Nice to know of an existing implementation. Here's a
recent thread that started up on it:
http://www.openldap.org/lists/openldap-devel/201102/msg00005.html
Would be interesting to see how their implementation of transactions
combines with syncRepl now in the picture. Specifically, I'm wondering
if replication will trigger on transaction boundaries, rather than on
each change in the transaction. Also wondering how change sequence
numbers will be impacted.
I'm wondering too! Many open questions with this spec. Though I'll note,
RFC4533 explicitly states (of syncrepl) "This protocol is not intended to be
used in applications requiring transactional data consistency." (Section
1.2)
I was hoping you guys already figured that all out :-).
If folks are looking for transactional consistency in replication, we should
probably develop a new spec to address that.
Seems so now, thanks for the heads up.
Syncrepl only promises eventual convergence, so there's really no reasonable
way to expect transactional consistency from it. Consider a replica operating
in refreshOnly mode, polling once every few minutes - between refreshes, it's
out of date anyway. When it pulls down a refresh, it will be receiving entries
one at a time; they could represent completed multi-entry transactions or not,
and any client querying the replica will see in-between state during that refresh.
You could conceivably try to make refreshAndPersist transactional - during the
persist phase, you can send along the transaction controls with the entry
updates. Since basically the slapd implementation is to queue up all
operations of the transaction until the final Commit is received, and then
write all at once, this will impose some noticeable latency between the
provider and the consumer. The Consumer would then do the same, queuing up all
the received writes until it also receives the Commit message from the
provider. So assuming perfect networks and perfect hardware and software, you
could propagate the transactional state down the line. The changes would
become visible atomically, but at staggered intervals relative to the
execution time on the original server. But if any network link is broken, the
consumer has to catch up again by using a refresh phase, and the transactional
consistency is lost during that time.
I guess for delta syncrepl, since we record changes in a log and play them
back in a known order, we could preserve the transactional state as well.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
