[ https://jira.jboss.org/browse/ISPN-715?page=com.atlassian.jira.plugin.sys... ] Mircea Markus commented on ISPN-715: ------------------------------------ thinking about it not sure how that would reduce number of deadlocks? [14:57] mmarkus: or cause deadlocks [14:58] an1310: ? [14:59] an1310: You would only acquire the one lock. If node A and node B both acquired a local lock, but we hashed to node C, wouldn't that be a deadlock? [15:01] mmarkus: so we have tx1 running on A, tx2 running on B and both work on a key that's hashed to C [15:01] mmarkus: is this your scenario? [15:03] an1310: Yes, unless there's some way that I could tell my app to always go to C (since that's where the data lives). [15:04] an1310: I'm colocating all the necessary caches involved in a tx on one data node and using that "eager lock single node" feature. [15:04] an1310: ...data on a cache; typing too fast. [15:04] mmarkus: returning to the example: how does that cause a deadlock? [15:05] mmarkus: i.e. the fact that I also acquire a local lock on A and B for key "k" which is hashed to C [15:06] an1310: I may be wrong about the deadlock part. [15:08] mmarkus: I don't see the benefit of it. Actually I think it would even cause performance faults: if another tx3 runs on A and tries to acquire lock on "k" which is held by tx1 then it would have to go to C and only then to timeout. Right now it would fail fast, without need to go to C -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/ISPN-715?page=com.atlassian.jira.plugin.sys... ] Mircea Markus resolved ISPN-715. -------------------------------- Resolution: Won't Fix see last comment -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira