"[EMAIL PROTECTED]" wrote : 
  | 
  | 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.
  | 

You still have an unrepeatable operation. It is not a good idea
to dynamically create logs (it might fail - no disk space - at just the wrong 
time).
Logs should be preallocated space and reused - you rewrite the log(s) from the 
memory
at checkpoints.

Like I said, the TM knows its currently active transactions. They are in its
memory state.

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=3860471#3860471

Reply to the post : 
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3860471


-------------------------------------------------------
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

Reply via email to