-
1. Re: Locks removal problem with JBossCache
belaban Nov 25, 2005 3:02 AM (in response to skipy)Which server is 192.168.20.90 ? A or B ?
-
2. Re: Locks removal problem with JBossCache
skipy Nov 25, 2005 3:08 AM (in response to skipy)"bela@jboss.com" wrote:
Which server is 192.168.20.90 ? A or B ?
192.168.20.90 is A server. This server is killed and error appears on B server (192.168.20.91)
Regards,
Eugene -
3. Re: Locks removal problem with JBossCache
belaban Nov 25, 2005 3:32 AM (in response to skipy)This could be caused by http://jira.jboss.com/jira/browse/JBCACHE-10.
Are you using
- synchronous replication and
- transactions ?
When you kill a coordinator after the PREPARE and before the COMMIT or ROLLBACK phase, this would be possible -
4. Re: Locks removal problem with JBossCache
skipy Nov 25, 2005 3:43 AM (in response to skipy)Yes, we use synchronous replication and transactions (JOTM). Killed server was not a coordinator according to logs, but the problem is exactly the same as what you describe.
So, if I understand correctly, this situation will be fixed in 1.3, when locks manipulating API will be removed. Before this version I have an ability to fix such situations manually. Am I right?
Regards,
Eugene -
5. Re: Locks removal problem with JBossCache
skipy Nov 25, 2005 3:47 AM (in response to skipy)BTW, when 1.3 version will be released approximately?
-
6. Re: Locks removal problem with JBossCache
belaban Nov 25, 2005 4:34 AM (in response to skipy)By 'coordinator' I *didn't* mean the JGroups coordinator, but the coordinator of the 2-phase-commit protocol, so the member on which a TX.commit() was called.
1.3. will be released in Feb/March 2006.
In the meantime you have to call TreeCache.releaseAllLocks(String fqn). -
7. Re: Locks removal problem with JBossCache
skipy Nov 25, 2005 4:42 AM (in response to skipy)"bela@jboss.com" wrote:
By 'coordinator' I *didn't* mean the JGroups coordinator, but the coordinator of the 2-phase-commit protocol, so the member on which a TX.commit() was called.
1.3. will be released in Feb/March 2006.
In the meantime you have to call TreeCache.releaseAllLocks(String fqn).
Ok, I understand. But wiil releaseAllLocks call be safe? E.g., if evict method of eviction policy is called - is there any garantee, that this node is not locked by active cluster node? If not - I can't call releaseAllLocks, because I can remove locks during open transaction, which is dangerous. -
8. Re: Locks removal problem with JBossCache
belaban Nov 25, 2005 4:58 AM (in response to skipy)No, releaseLocks() will release *all* locks !
I upgraded that JIRA issue from minor to critical. -
9. Re: Locks removal problem with JBossCache
skipy Nov 25, 2005 5:01 AM (in response to skipy)"bela@jboss.com" wrote:
No, releaseLocks() will release *all* locks !
I upgraded that JIRA issue from minor to critical.
That's what I was affraid of. Ok, I'll use deprecated API to get locks and to understand what locks should I remove.
Anyway, thank you!
Regards,
Eugene -
10. Re: Locks removal problem with JBossCache
skipy Nov 25, 2005 7:07 AM (in response to skipy)One more question. If I specify TransactionManagerLookup implementation for cache, but don't use transactions explicitely - will replications due to put calls be transactional? I.e., who will be the owner of lock on the other side - transaction or thread?
Regards,
Eugene -
11. Re: Locks removal problem with JBossCache
belaban Nov 25, 2005 8:03 AM (in response to skipy)Thread