Hi Nishida,
Your analysis is correct. I suggest that you post your comment on
SEQUOIA-1018 issue.
I have not looked carefully at these changes but this does not seem a
good idea to force a resume activity. What would happen if the activity
that suspended the vdb would finally successfully complete and try to
resume?
We should have a better way to track who triggered the suspend activity
and kill/cancel that activity to gracefully resume.
Thanks for your feedback,
Emmanuel
I have a question about RecoverThread.java.
I think it related to the issue SEQUOIA-1018 and the change to
RecoverThread.java in Revision 1.55.2.6.
At RecoverThread.java, Boolean.FALSE is assigned to recoveryProcessInterrupted and
recoveryProcessInterrupted is used as the lock object in run().
/sequoia/src/org/continuent/sequoia/controller/recoverylog/RecoverThread.java
(sequoia-2.10.10-src)
L.107
------------------
private Boolean recoveryProcessInterrupted = Boolean.FALSE;
------------------
L.225
------------------
synchronized (recoveryProcessInterrupted)
------------------
Boolean.FALSE is the static Boolean object.
I think it means all Boolean.FALSE in the Java process will be locked by this
code.
java.lang.Boolean.java
------------------
public static final Boolean TRUE = new Boolean(true);
------------------
public static final Boolean FALSE = new Boolean(false);
------------------
If some other modules (for example JDBC Driver) use Boolean.FALSE as the lock
object,
does RecoverThread wait for freeing Boolean.FALSE? (In the worst case, does it
wait forever?)
Thanks and Regards,
--
Emmanuel Cecchet
FTO @ Frog Thinker
Open Source Development & Consulting
--
Web: http://www.frogthinker.org
email: [EMAIL PROTECTED]
Skype: emmanuel_cecchet
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
