[Date Prev][Date Next]
Re: syncrepl simplification
Kurt D. Zeilenga wrote:
At 09:19 PM 1/12/2005, Howard Chu wrote:That actually makes sense, although the current code doesn't allow for
this. It would require the sessionlog config directive to take a search
specifier (baseDN of a subtree at least) to differentiate logs. Again
this is problematic when you're dealing with ModDN requests; if an entry
moves across a sessionlog boundary then one or both logs becomes useless.
Kurt D. Zeilenga wrote:
I'll have to think about that some more.
The rationale, I believe, for multiple consumer contexts
within a database context was that administrators could state
different consumer policies for different areas of the DIT.
I've been, too. In particular, I think the above rationale more
applies to provider contexts, where one might want to have different
server handling of different requests. For instance, one might
want to have one area covered by a session log and one area not.
At the moment all updates in a context are recorded in all the active
sessionlogs, so the only difference between the multiple logs is their
size. This also seems unnecessary, it would be best to have a single log
of the largest practical size. I have a feeling this sessionlog stuff
was not thoroughly thought out; the fact that there is no config keyword
for the sid on the consumer implies to me that it was never even tested
Given all of this, I think it would be best to have only one sessionlog
per provider, and we can forget about the sid parameter entirely.
On the consumer side, we just just require additional
database contexts where the admin desires different consumer
To me, it still sounds like a recipe for disaster. If the separate consumer contexts are talking to different providers, then you have the cascade problem I mentioned before. If the contexts are all pulling from the same provider, then I guess it works. I still don't see any rationale for the updatedn on the consumer; surely any data that the provider returns must satisfy the consumer criteria and therefore must be reflected into the consumer DB.
I concur with regards to the updatedn. Also, we need to revisit
consumer ACLs. Seems odd to me that syncrepl consumer needs
permission to write into its own database.
Yes. OK, I'm going to delete the updatedn stuff then.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support