|
|
Hi Tridge,
>unfortunately it would means that on a crash we would lose info. We
>would have records with usnChanged > highestCommittedUSN, which might
>have implications for replication. Having gone to the trouble of
>adding safe transactions and journaling to tdb I don't want to go back :-)
Right, but when you startup you can just search for all entries where
usnChanged > highestCommittedUSN, and then update the in-memory NC
high watermark.
>We already maintain a sequenceNumber that behaves just like
>highestCommittedUSN in @BASEINFO inside ldb, so I'm inclined to just
>use that.
Sure, if you have it, use it -- this is just an optimization.
> > None, although it's possible if you want because the USN namespace is
> > NC-local as far as replication is concerned.
>
>interesting - I assumed it would matter, at the very least for our NT4
>style samsync replication. What do you use for that in XAD ?
In XAD we manage highestCommittedUSN like contextCSN in OpenLDAP, ie.
stored in memory and checkpointed at regular intervals (with recovery
as described above). We actually have a global highestCommittedUSN
but this is more for XAD-specific implementation reasons than trying
to mimic Windows behaviour.
-- Luke
--
|
|