Alex Karasulu wrote:
Hmm I see what you're thinking. I think we're all having problems drawing
distinctions between these various facilities in the server. I know I have
wavered myself.
At first I was thinking we should have an extremely simple journal with
markers tracking application of operations. Some conversations with Emmanuel
then lead me to believe that using the CL as the journal was just as good.
Now I feel it might not be such a good idea. Let me list my thoughts:
(1) The CL is highly indexed with several db files which means there will be
many writes need to persist the record while keeping the CL and it's indices
consistent. Also the CL is deep inside the server in the interceptor chain
and many things can go wrong while getting to that point, not to mention the
processing time it takes to get there.
(2) The CL should be used for auditing, versioning, snapshoting, and
replication. It is fast thanks to indices and will should all the
operations that have succeeded in inducing changes. It would get more
complicated if we started using it to also capture operations before they
have been applied. The semantics would shift.
(3) As you say the CL itself can get corrupted. And for this reason it's
not well suited as a journal for all (even in progress) operations.
I'm seriously thinking the use of the CL for a journal is not a good
decision. The journal needs to be fast and simple, doing only one thing and
doing it fast and flawlessly.
Seems like we are now converging on the same vision :) The journal must
be as fast as possible, and dedicated to a very basic usage : DRS
For replication, we need a slightly more complex data structure, thus
the CL.
But we can just see the CL as a bunch of indexes built on top of the
journal.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
