"[EMAIL PROTECTED]" wrote : | I like the idea of a RecoverableMBean. That is similar to what OTS provides. | | That has a couple of problems: | | 1) One of the MBeans might have failed to start or is no longer deployed. | The recovery could be incomplete/inaccurate unless there is a predefined list | of expected resources. | 2) Renaming log files is bad. It is not a repeatable process. What happens if it fails again | during recovery. | 3) Timestamps are bad, especially if you want to move the log to a different | server with a uncorrelated up clock. | |
Ok, then it would be implemented as follows: 1. TM depends on RecoveryManager 2. Recovery manager records prexisting log files. 3. Recovery Manager creates new log files. 4. Everybody starts up. 5. Recover Manager receives START notification. Starts recovering on prexisting recorded file list. anonymous wrote : | The reason for using the DB is as follows: | a) It is usually a part of the transaction already | b) It is easy to implement | c) It fixes the final problem for a local db | i.e. when using the last resource gambit, there is no way to know whether | the db commit worked or failed if the AS fails during the DB commit invocation. Seems this would only work if the logger was the same DataSource as the Gambitted resource. Bill View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3860467#3860467 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3860467 ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ JBoss-Development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-development
