Thread
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3909052#3909052
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3909052
---
This SF.net email is sponsored by: Spl
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
View the original post
"[EMAIL PROTECTED]" 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
View the orig
No, releaseLocks() will release *all* locks !
I upgraded that JIRA issue from minor to critical.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3909004#3909004
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3909004
"[EMAIL PROTECTED]" 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(St
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).
View the original post :
BTW, when 1.3 version will be released approximately?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3908990#3908990
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3908990
---
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 t
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
View the original post :
http://www.jboss.com/index.h
"[EMAIL PROTECTED]" 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
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3908986#3908986
Reply to the po
Which server is 192.168.20.90 ? A or B ?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3908984#3908984
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3908984
---
This
11 matches
Mail list logo
