Sam, as workaround you can use IgniteQueue in order to implement distributed exclusive lock. You can find example of such solution in vertx-ignite project. See IgniteClusterManager class [1], getLockWithTimeout() method and LockImpl class.
[1] https://github.com/vert-x3/vertx-ignite/blob/master/src/main/java/io/vertx/spi/cluster/ignite/IgniteClusterManager.java On Thu, Sep 8, 2016 at 1:49 AM, [email protected] < [email protected]> wrote: > With Key Vs Entry lock, I am talking about lock granularity. > Key lock is kind of synchronous block or method which have processing logic > unrelated to the key or cached data being processed but a different shared > resource. Kind of distributed mutex. but note that it does not need all > other feature from a distributed cache access semantic. > Entry lock is a distributed cache lock with all data access semantics. It > can be seen as row level lock for a DB system. > It is good to have, but not necessary. Entry lock can achieve what key lock > need to do. > > Few last question on Locks - > 1. Is there a way to have time-to-live for a lock? what happens > thread/system got killed before unlocking? > 2. Locks works only with TRANSACTIONAL mode, is there approx benchmark > which > can be shared for FETCH/PUT/FECTCHALL/PUTALL comparing TRANSACTIONAL vs > ATOMIC? > > For key lock scenario above, I can have a separate cache just for locks > (Transnational) and separate cache for data (Atomic), but want to decide is > that really needed. > > Thanks, > -Sam > > > > > > -- > View this message in context: http://apache-ignite-users. > 70518.x6.nabble.com/understanding-Locks-usage-tp7489p7596.html > Sent from the Apache Ignite Users mailing list archive at Nabble.com. > -- Andrey Gura GridGain Systems, Inc. www.gridgain.com
