directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <elecha...@gmail.com>
Subject [ChangeLog] Basic design
Date Wed, 26 Sep 2007 16:02:39 GMT
Hi,

as I'm trying to muse around the ChangeLog interceptor, to help unit
tests to be faster, I have a load of question here.

Basically, what we want is a way to play tests which will let the
server in its original state even after any kind of modification. We
need an activable rollback mechanism here.

Suppose we want to play for a while on the data, here is the sequence
of operation I'm thinking about :
1) start a 'Mark' (I prefer using 'Mark' instead of 'Transaction', for
semantic reasons)
3) inject whatever we want into the server (add, del, modify...)
4) do a rollback (the anti-operations are committed)

At the end, the server will be in a consistent state.

This leads to some tricky points :
1) Some partitions may be treated differently (schema ?) : we may need
a level of protection
2) The logger will become a bottleneck, as we will have to synchornize
the concurrent access to the storage
3) if we want to rollback the operations, the server should not be
able to process any other operations until the rollback is done

If we seriously consider using this mechanism for something more
critical, like storing a journal we can replay on crash (usefull with
the differed write mechanism we have), then other elements come into
the play :
1) we must flush the data as soon as they arrive, on disk
2) we have to think about a recover mechanism, which should compare
the current database state and the current journal
2-1) this recover mechanism will have to know which data has been
flushed to the backend, otherwise we may have a difference between the
journal and the backend. Namely, the Sync thread should be driven by
the ChangeLog interceptor (when the commit is submitted, then the
synch thread is waken up and flush data on the backend, marking the
entries in the log when they are written)

In any case, we also need a mechnaism to activate the ChangeLog operations :
- startLog
- beginMark
- commit
- rollback
- stopLog

What would be the best solution ? We can do that with a specific
control, an extendedOperation or a standard modifyRequest of a
specific entry in the ou=system partition (remember the 'configuration
in the DIT' thing ?) coupled with a trigger and SP.

thoughts ?


-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com

Mime
View raw message