1. Lock is acquired on per entry (per-key) basis. Can you please provide threaddumps and logs from all of the nodes. Note, that locks are bound to the thread they are acquired in.
2. It seems the answer is NO. One option though - you can stop the node holding the lock, i.e. node where cache.lock(key).lock(); succeeded. In this case lock will be released on server node and next candidate should succeed. Can you please explain why you use cache locks. In most cases cache locks in code can be replaced with cache transactions and it seems to me you try to replace tx locking with explicit locks which looks like overhead to me. Use try-with-resources notation to work with txs. This should prevent you from having unreleased locks. --Yakov 2017-01-17 1:44 GMT+03:00 styriver <[email protected]>: > I have two questions about locking. > > 1) Is it expected behavior that if an application fails to call an unlock > it > locks the entire cache and not just that object? > > We have a web application that had a bug where unlock was not being called. > But the behavior that we experienced is that this affected all users. All > users were "hung" until we restarted both server nodes to free the lock. > The > cache in question uses the userid as a key. So it appears we lock the > entire > cache not just a particular map entry. When we ask for the lock we are > asking based on the map key? > > Lock lock = getCache().lock(userId); > > try { > if (getCache().containsKey(userId)) { > lockedObj = new LockedObj(lock, getCache().get(userId)); > //acquire lock > lock.lock(); > } > > 2) Is there a way to "force" an unlock in the event. The only way I could > figure out to resolve the issues was to take down both server nodes that > hold the cache and restart them. > > > > > -- > View this message in context: http://apache-ignite-users. > 70518.x6.nabble.com/Locking-behavior-tp10087.html > Sent from the Apache Ignite Users mailing list archive at Nabble.com. >
