Niraj,
I like the idea of a fake recovery log. Would the general idea be to
just throw away any data sent to it? While I haven't looked at the
recoverylog code in detail, this just seems to be a matter of creating
a subclass (or an interface) for
controller.recoverylog.RecoveryLog.java and modifying both the DTD and
controller.recoverlog.DatabasesParser.java to allow a null log to be
specified.
You can look at what I did for the EmbeddedRecoveryLog (look at Version
Control history of https://forge.continuent.org/jira/browse/SEQUOIA-471).
I would recommend to inherit from EmbeddedRecoveryLog and override
methods that log data in the log table with empty methods. You should
still keep the methods accessing the backend and checkpoint tables to
make sure that the remaining logic does not crash. But be aware that no
consistency between backends will be guaranteed and you can easily mess
with backend states with an inconsistent recovery log. But I guess that
you know what you do.
You can alter DTD and DatabasesParser the same way as I did for the
embedded log.
Keep us posted with your progress,
Emmanuel
--
Emmanuel Cecchet
Chief Scientific Officer, Continuent
Blog: http://emanux.blogspot.com/
Open source: http://www.continuent.org
Corporate: http://www.continuent.com
Skype: emmanuel_cecchet
Cell: +33 687 342 685
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
