[
https://jira.jboss.org/jira/browse/JBAS-7851?page=com.atlassian.jira.plug...
]
Brian Stansberry updated JBAS-7851:
-----------------------------------
Description:
Callers asking for a lock should be able to distinguish these cases:
1) Lock can't be obtained
2) Lock obtained, and node already held it.
3) Lock obtained, but the node had to make a group RPC to get it
Purpose of this is to use condition 3) as a way to detect failover.
Related to this, the API should also support creation of a new lock category such that the
node immediately owns the lock with no group RPC.
was:
Callers asking for a lock should be able to distinguish these cases:
1) Lock can't be obtained
2) Lock obtained, and node already held it.
3) Lock obtained, but the node had to make a group RPC to get it
Related to this, the API should also support creation of a new lock category such that the
node immediately owns the lock with no group RPC.
Distributed locking API should indicate whether taking lock from
another node was necessary
-------------------------------------------------------------------------------------------
Key: JBAS-7851
URL:
https://jira.jboss.org/jira/browse/JBAS-7851
Project: JBoss Application Server
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Clustering
Reporter: Brian Stansberry
Fix For: JBossAS-6.0.0.M4
Callers asking for a lock should be able to distinguish these cases:
1) Lock can't be obtained
2) Lock obtained, and node already held it.
3) Lock obtained, but the node had to make a group RPC to get it
Purpose of this is to use condition 3) as a way to detect failover.
Related to this, the API should also support creation of a new lock category such that
the node immediately owns the lock with no group RPC.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira