Mixing
global distributed lock that can be set to expire Java
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
I have a use case where I want to have a globally distributed lock. We started out using SELECT .. FOR UPDATE, but that quickly started to have problems as we scaled up the number of servers. Also it didn't account for processes that checked out the lock and then died and failed to return the lock.
We need to be able to set an expiration on the lock (i.e. if the process who checked out the lock does not return it in 2 hours, the lock is automatically returned to the pool). I realize that this introduces the issue where we are ignoring locks, but we are fairly certain that the process has died if not complete in 2 hours. Also the job is idempotent, so if it is done more than once it's not a big deal.
I've looked through a number of distributed locking systems and come across this questions that have been extremely helpful. All of the solutions extend off of Java's java.util.concurrency.locks.Lock, which actually may be the issue I'm coming across because that interface doesn't have the expiration feature I need. We have a similar strategy to mongo-java-distributed-lock where we use MongoDB's findAndModify. We're considering:
- mongo-java-distributed-lock
- Redisson
hazelcast
as our distributed locking mechanism (all happen to implement java.util.concurrency.locks.Lock).
The biggest problem is that because java.util.concurrency.locks.Lock doesn't have an option for expiring a lock, these don't fit all the goals. This answer probably gets closest with hazelcast, but it is reliant on an entire server failing, not just a thread taking too long. Another option is possibly using a Samaphore with hazelcast as described here. I could have a reaper thread that is then able to cancel the locks of others if they are taking too long. With Mongo and Redis I could take advantage of their ability to expire objects, but that doesn't seem to be part of either of the libraries since they just implement java.util.concurrency.locks.Lock in the end.
So this was just a long winded way of asking, is there a distributed locking mechanism out there that I can have automatically expire after N seconds? Should I be looking at a different mechanism than java.util.concurrency.locks.Lock in this situation altogether?
java concurrency locking semaphore distributed-lock
edited May 23 '17 at 12:17
Community♦
11
asked Mar 31 '14 at 16:26
ScottScott
12.7k1062112
add a comment |
I have a use case where I want to have a globally distributed lock. We started out using SELECT .. FOR UPDATE, but that quickly started to have problems as we scaled up the number of servers. Also it didn't account for processes that checked out the lock and then died and failed to return the lock.
We need to be able to set an expiration on the lock (i.e. if the process who checked out the lock does not return it in 2 hours, the lock is automatically returned to the pool). I realize that this introduces the issue where we are ignoring locks, but we are fairly certain that the process has died if not complete in 2 hours. Also the job is idempotent, so if it is done more than once it's not a big deal.
I've looked through a number of distributed locking systems and come across this questions that have been extremely helpful. All of the solutions extend off of Java's java.util.concurrency.locks.Lock, which actually may be the issue I'm coming across because that interface doesn't have the expiration feature I need. We have a similar strategy to mongo-java-distributed-lock where we use MongoDB's findAndModify. We're considering:
- mongo-java-distributed-lock
- Redisson
hazelcast
as our distributed locking mechanism (all happen to implement java.util.concurrency.locks.Lock).
The biggest problem is that because java.util.concurrency.locks.Lock doesn't have an option for expiring a lock, these don't fit all the goals. This answer probably gets closest with hazelcast, but it is reliant on an entire server failing, not just a thread taking too long. Another option is possibly using a Samaphore with hazelcast as described here. I could have a reaper thread that is then able to cancel the locks of others if they are taking too long. With Mongo and Redis I could take advantage of their ability to expire objects, but that doesn't seem to be part of either of the libraries since they just implement java.util.concurrency.locks.Lock in the end.
So this was just a long winded way of asking, is there a distributed locking mechanism out there that I can have automatically expire after N seconds? Should I be looking at a different mechanism than java.util.concurrency.locks.Lock in this situation altogether?
java concurrency locking semaphore distributed-lock
edited May 23 '17 at 12:17
Community♦
11
asked Mar 31 '14 at 16:26
ScottScott
12.7k1062112
If you're happy rolling your own then you could consider extending Lock and adding a static watcher thread that keeps a list of live locks and periodically checks expiration times.
– selig
Apr 1 '14 at 14:34
I'd love rolling my own, but also don't want to re-invent the wheel if there is a solution already out there to do this.
– Scott
Apr 1 '14 at 16:59
Possible duplicate: stackoverflow.com/questions/1059580/distributed-lock-service
– flup
Apr 14 '14 at 22:43
@flup, I'm explicitly asking for a solution that offers an expiring lock. All the other SO questions are only about distributed locks, not distributed expiring locks, the key feature I care about.
– Scott
Apr 16 '14 at 20:18
add a comment |
I have a use case where I want to have a globally distributed lock. We started out using SELECT .. FOR UPDATE, but that quickly started to have problems as we scaled up the number of servers. Also it didn't account for processes that checked out the lock and then died and failed to return the lock.
We need to be able to set an expiration on the lock (i.e. if the process who checked out the lock does not return it in 2 hours, the lock is automatically returned to the pool). I realize that this introduces the issue where we are ignoring locks, but we are fairly certain that the process has died if not complete in 2 hours. Also the job is idempotent, so if it is done more than once it's not a big deal.
I've looked through a number of distributed locking systems and come across this questions that have been extremely helpful. All of the solutions extend off of Java's java.util.concurrency.locks.Lock, which actually may be the issue I'm coming across because that interface doesn't have the expiration feature I need. We have a similar strategy to mongo-java-distributed-lock where we use MongoDB's findAndModify. We're considering:
- mongo-java-distributed-lock
- Redisson
hazelcast
as our distributed locking mechanism (all happen to implement java.util.concurrency.locks.Lock).
The biggest problem is that because java.util.concurrency.locks.Lock doesn't have an option for expiring a lock, these don't fit all the goals. This answer probably gets closest with hazelcast, but it is reliant on an entire server failing, not just a thread taking too long. Another option is possibly using a Samaphore with hazelcast as described here. I could have a reaper thread that is then able to cancel the locks of others if they are taking too long. With Mongo and Redis I could take advantage of their ability to expire objects, but that doesn't seem to be part of either of the libraries since they just implement java.util.concurrency.locks.Lock in the end.
So this was just a long winded way of asking, is there a distributed locking mechanism out there that I can have automatically expire after N seconds? Should I be looking at a different mechanism than java.util.concurrency.locks.Lock in this situation altogether?
java concurrency locking semaphore distributed-lock
edited May 23 '17 at 12:17
Community♦
11
asked Mar 31 '14 at 16:26
ScottScott
12.7k1062112
I have a use case where I want to have a globally distributed lock. We started out using SELECT .. FOR UPDATE, but that quickly started to have problems as we scaled up the number of servers. Also it didn't account for processes that checked out the lock and then died and failed to return the lock.
We need to be able to set an expiration on the lock (i.e. if the process who checked out the lock does not return it in 2 hours, the lock is automatically returned to the pool). I realize that this introduces the issue where we are ignoring locks, but we are fairly certain that the process has died if not complete in 2 hours. Also the job is idempotent, so if it is done more than once it's not a big deal.
I've looked through a number of distributed locking systems and come across this questions that have been extremely helpful. All of the solutions extend off of Java's java.util.concurrency.locks.Lock, which actually may be the issue I'm coming across because that interface doesn't have the expiration feature I need. We have a similar strategy to mongo-java-distributed-lock where we use MongoDB's findAndModify. We're considering:
- mongo-java-distributed-lock
- Redisson
hazelcast
as our distributed locking mechanism (all happen to implement java.util.concurrency.locks.Lock).
The biggest problem is that because java.util.concurrency.locks.Lock doesn't have an option for expiring a lock, these don't fit all the goals. This answer probably gets closest with hazelcast, but it is reliant on an entire server failing, not just a thread taking too long. Another option is possibly using a Samaphore with hazelcast as described here. I could have a reaper thread that is then able to cancel the locks of others if they are taking too long. With Mongo and Redis I could take advantage of their ability to expire objects, but that doesn't seem to be part of either of the libraries since they just implement java.util.concurrency.locks.Lock in the end.
So this was just a long winded way of asking, is there a distributed locking mechanism out there that I can have automatically expire after N seconds? Should I be looking at a different mechanism than java.util.concurrency.locks.Lock in this situation altogether?
java concurrency locking semaphore distributed-lock
java concurrency locking semaphore distributed-lock
edited May 23 '17 at 12:17
Community♦
11
asked Mar 31 '14 at 16:26
ScottScott
12.7k1062112
edited May 23 '17 at 12:17
Community♦
11
asked Mar 31 '14 at 16:26
ScottScott
12.7k1062112
edited May 23 '17 at 12:17
Community♦
11
edited May 23 '17 at 12:17
Community♦
11
edited May 23 '17 at 12:17
Community♦
11
11
asked Mar 31 '14 at 16:26
ScottScott
12.7k1062112
asked Mar 31 '14 at 16:26
ScottScott
12.7k1062112
asked Mar 31 '14 at 16:26
ScottScott
12.7k1062112
12.7k1062112
If you're happy rolling your own then you could consider extending Lock and adding a static watcher thread that keeps a list of live locks and periodically checks expiration times.
– selig
Apr 1 '14 at 14:34
I'd love rolling my own, but also don't want to re-invent the wheel if there is a solution already out there to do this.
– Scott
Apr 1 '14 at 16:59
Possible duplicate: stackoverflow.com/questions/1059580/distributed-lock-service
– flup
Apr 14 '14 at 22:43
@flup, I'm explicitly asking for a solution that offers an expiring lock. All the other SO questions are only about distributed locks, not distributed expiring locks, the key feature I care about.
– Scott
Apr 16 '14 at 20:18
add a comment |
If you're happy rolling your own then you could consider extending Lock and adding a static watcher thread that keeps a list of live locks and periodically checks expiration times.
– selig
Apr 1 '14 at 14:34
I'd love rolling my own, but also don't want to re-invent the wheel if there is a solution already out there to do this.
– Scott
Apr 1 '14 at 16:59
Possible duplicate: stackoverflow.com/questions/1059580/distributed-lock-service
– flup
Apr 14 '14 at 22:43
@flup, I'm explicitly asking for a solution that offers an expiring lock. All the other SO questions are only about distributed locks, not distributed expiring locks, the key feature I care about.
– Scott
Apr 16 '14 at 20:18
If you're happy rolling your own then you could consider extending Lock and adding a static watcher thread that keeps a list of live locks and periodically checks expiration times.
– selig
Apr 1 '14 at 14:34
If you're happy rolling your own then you could consider extending Lock and adding a static watcher thread that keeps a list of live locks and periodically checks expiration times.
– selig
Apr 1 '14 at 14:34
I'd love rolling my own, but also don't want to re-invent the wheel if there is a solution already out there to do this.
– Scott
Apr 1 '14 at 16:59
I'd love rolling my own, but also don't want to re-invent the wheel if there is a solution already out there to do this.
– Scott
Apr 1 '14 at 16:59
Possible duplicate: stackoverflow.com/questions/1059580/distributed-lock-service
– flup
Apr 14 '14 at 22:43
Possible duplicate: stackoverflow.com/questions/1059580/distributed-lock-service
– flup
Apr 14 '14 at 22:43
@flup, I'm explicitly asking for a solution that offers an expiring lock. All the other SO questions are only about distributed locks, not distributed expiring locks, the key feature I care about.
– Scott
Apr 16 '14 at 20:18
@flup, I'm explicitly asking for a solution that offers an expiring lock. All the other SO questions are only about distributed locks, not distributed expiring locks, the key feature I care about.
– Scott
Apr 16 '14 at 20:18
add a comment |
4 Answers
4
active
oldest
votes
You may use Redisson based on Redis server. It implements familiar Java data structures including java.util.Lock with distributed and scalable abilities. Including ability to setup lock release timeout. Usage example:
Config config = new Config();
// for single server
config.useSingleServer()
.setAddress("127.0.0.1:6379");
// or
// for master/slave servers
config.useSentinelConnection()
.setMasterName("mymaster")
.addSentinelAddress("127.0.0.1:26389", "127.0.0.1:26379");
Redisson redisson = Redisson.create(config);
Lock lock = redisson.getLock("anyLock");
try {
// unlock automatically after 10 seconds of hold
lock.lock(10, TimeUnit.SECONDS);
} finally {
lock.unlock();
}
...
redisson.shutdown();
answered Jul 15 '14 at 18:12
Nikita KoksharovNikita Koksharov
6,2963754
Linking to other answer as well for this feature in case someone else comes across. stackoverflow.com/a/21072066/311525
– Scott
Aug 26 '14 at 22:48
What happens to the lock if the holding process dies?
– Mike Stoddart
Oct 5 '18 at 16:23
1
@MikeStoddart Redisson maintains lock watchdog, it prolongs lock expiration while lock holder Redisson instance is alive.
– Nikita Koksharov
Oct 5 '18 at 16:28
Thanks @NikitaKoksharov, which I assume means the lock isn't released when the holding process dies, but rather when the watchdog cleans it up?
– Mike Stoddart
Oct 6 '18 at 17:44
1
@MikeStoddart lock would be released automatically if watchdog won't extend it. If process dies then watchdog dies either and thus lock will be released since it wasn't extended
– Nikita Koksharov
Oct 8 '18 at 14:24
add a comment |
You should consider using zookeeper. And there is an easy to use library for these kind of "distributed" stuff which is built on top of zookeeper : curator framework. I think what you are looking for is shared reentrant lock. You can also check other locks in recipes.
answered Apr 16 '14 at 8:42
frailfrail
3,78622234
I did not see where zookeeper provided expiring locks. I'm aware of it as a solution for distributed locks, but it didn't seem to offer the expiring feature I was looking for. If that feature does exist, can you provide a link to it as I was not able to find it.
– Scott
Apr 16 '14 at 20:19
well in zookeeper the lock would expire if the lock owner session drop which happens just like your hazelcast example. I can understand your "crash" concerns; but giving a timeout for a lock itself seems weird at best :)
– frail
Apr 16 '14 at 21:17
I get the 'crash' portion. The use case is I have many Actors locking assets. One of those actors dies, but the server still hums along. The work that actor was working on needs to go back into the pool after a period of time to avoid that work never being done. The work is idempotent, so I don't care it gets done twice, just that it gets done. I don't think this is 'weird', it has come up more than a few times as a requirement for me.
– Scott
Apr 17 '14 at 14:08
add a comment |
What about this one?
http://www.gemstone.com/docs/5.5.0/product/docs/japi/com/gemstone/gemfire/distributed/DistributedLockService.html
Its lock method seems to have what you need:
public abstract boolean lock(Object name,
long waitTimeMillis,
long leaseTimeMillis)
Attempts to acquire a lock named name. Returns true as soon as the lock is acquired. If the lock is currently held by another thread in this or any other process in the distributed system, or another thread in the system has locked the entire service, this method keeps trying to acquire the lock for up to waitTimeMillis before giving up and returning false. If the lock is acquired, it is held until unlock(Object name) is invoked, or until leaseTimeMillis milliseconds have passed since the lock was granted - whichever comes first.
answered Apr 16 '14 at 21:20
xxaxxa
896616
add a comment |
Actually, as far as I can tell mongo-java-distributed-lock has the ability to expire a lock through the use of DistributedLockOptions.setInactiveLockTimeout()
I haven't tried it yet, but think I will...
EDIT: I have now also tried it, and it works well...
String lockName = "com.yourcompany.yourapplication.somelock";
int lockTimeoutMilliSeconds = 500;
String dbURI = CWConfig.get().getMongoDBConfig().getDbURI();
DistributedLockSvcFactory lockSvcFactory = new DistributedLockSvcFactory(new DistributedLockSvcOptions(dbURI));
DistributedLockSvc lockSvc = lockSvcFactory.getLockSvc();
DistributedLock lock = lockSvc.create(lockName);
lock.getOptions().setInactiveLockTimeout(lockTimeoutMilliSeconds);
try {
lock.lock();
// Do work
} finally {
lock.unlock();
}
answered May 31 '16 at 13:03
linusnlinusn
114
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f22766988%2fglobal-distributed-lock-that-can-be-set-to-expire-java%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
You may use Redisson based on Redis server. It implements familiar Java data structures including java.util.Lock with distributed and scalable abilities. Including ability to setup lock release timeout. Usage example:
Config config = new Config();
// for single server
config.useSingleServer()
.setAddress("127.0.0.1:6379");
// or
// for master/slave servers
config.useSentinelConnection()
.setMasterName("mymaster")
.addSentinelAddress("127.0.0.1:26389", "127.0.0.1:26379");
Redisson redisson = Redisson.create(config);
Lock lock = redisson.getLock("anyLock");
try {
// unlock automatically after 10 seconds of hold
lock.lock(10, TimeUnit.SECONDS);
} finally {
lock.unlock();
}
...
redisson.shutdown();
answered Jul 15 '14 at 18:12
Nikita KoksharovNikita Koksharov
6,2963754
Linking to other answer as well for this feature in case someone else comes across. stackoverflow.com/a/21072066/311525
– Scott
Aug 26 '14 at 22:48
What happens to the lock if the holding process dies?
– Mike Stoddart
Oct 5 '18 at 16:23
1
@MikeStoddart Redisson maintains lock watchdog, it prolongs lock expiration while lock holder Redisson instance is alive.
– Nikita Koksharov
Oct 5 '18 at 16:28
Thanks @NikitaKoksharov, which I assume means the lock isn't released when the holding process dies, but rather when the watchdog cleans it up?
– Mike Stoddart
Oct 6 '18 at 17:44
1
@MikeStoddart lock would be released automatically if watchdog won't extend it. If process dies then watchdog dies either and thus lock will be released since it wasn't extended
– Nikita Koksharov
Oct 8 '18 at 14:24
add a comment |
You may use Redisson based on Redis server. It implements familiar Java data structures including java.util.Lock with distributed and scalable abilities. Including ability to setup lock release timeout. Usage example:
Config config = new Config();
// for single server
config.useSingleServer()
.setAddress("127.0.0.1:6379");
// or
// for master/slave servers
config.useSentinelConnection()
.setMasterName("mymaster")
.addSentinelAddress("127.0.0.1:26389", "127.0.0.1:26379");
Redisson redisson = Redisson.create(config);
Lock lock = redisson.getLock("anyLock");
try {
// unlock automatically after 10 seconds of hold
lock.lock(10, TimeUnit.SECONDS);
} finally {
lock.unlock();
}
...
redisson.shutdown();
answered Jul 15 '14 at 18:12
Nikita KoksharovNikita Koksharov
6,2963754
Linking to other answer as well for this feature in case someone else comes across. stackoverflow.com/a/21072066/311525
– Scott
Aug 26 '14 at 22:48
What happens to the lock if the holding process dies?
– Mike Stoddart
Oct 5 '18 at 16:23
1
@MikeStoddart Redisson maintains lock watchdog, it prolongs lock expiration while lock holder Redisson instance is alive.
– Nikita Koksharov
Oct 5 '18 at 16:28
Thanks @NikitaKoksharov, which I assume means the lock isn't released when the holding process dies, but rather when the watchdog cleans it up?
– Mike Stoddart
Oct 6 '18 at 17:44
1
@MikeStoddart lock would be released automatically if watchdog won't extend it. If process dies then watchdog dies either and thus lock will be released since it wasn't extended
– Nikita Koksharov
Oct 8 '18 at 14:24
add a comment |
You may use Redisson based on Redis server. It implements familiar Java data structures including java.util.Lock with distributed and scalable abilities. Including ability to setup lock release timeout. Usage example:
Config config = new Config();
// for single server
config.useSingleServer()
.setAddress("127.0.0.1:6379");
// or
// for master/slave servers
config.useSentinelConnection()
.setMasterName("mymaster")
.addSentinelAddress("127.0.0.1:26389", "127.0.0.1:26379");
Redisson redisson = Redisson.create(config);
Lock lock = redisson.getLock("anyLock");
try {
// unlock automatically after 10 seconds of hold
lock.lock(10, TimeUnit.SECONDS);
} finally {
lock.unlock();
}
...
redisson.shutdown();
answered Jul 15 '14 at 18:12
Nikita KoksharovNikita Koksharov
6,2963754
You may use Redisson based on Redis server. It implements familiar Java data structures including java.util.Lock with distributed and scalable abilities. Including ability to setup lock release timeout. Usage example:
Config config = new Config();
// for single server
config.useSingleServer()
.setAddress("127.0.0.1:6379");
// or
// for master/slave servers
config.useSentinelConnection()
.setMasterName("mymaster")
.addSentinelAddress("127.0.0.1:26389", "127.0.0.1:26379");
Redisson redisson = Redisson.create(config);
Lock lock = redisson.getLock("anyLock");
try {
// unlock automatically after 10 seconds of hold
lock.lock(10, TimeUnit.SECONDS);
} finally {
lock.unlock();
}
...
redisson.shutdown();
answered Jul 15 '14 at 18:12
Nikita KoksharovNikita Koksharov
6,2963754
edited Mar 19 '17 at 18:53
answered Jul 15 '14 at 18:12
Nikita KoksharovNikita Koksharov
6,2963754
answered Jul 15 '14 at 18:12
Nikita KoksharovNikita Koksharov
6,2963754
answered Jul 15 '14 at 18:12
Nikita KoksharovNikita Koksharov
6,2963754
6,2963754
Linking to other answer as well for this feature in case someone else comes across. stackoverflow.com/a/21072066/311525
– Scott
Aug 26 '14 at 22:48
What happens to the lock if the holding process dies?
– Mike Stoddart
Oct 5 '18 at 16:23
1
@MikeStoddart Redisson maintains lock watchdog, it prolongs lock expiration while lock holder Redisson instance is alive.
– Nikita Koksharov
Oct 5 '18 at 16:28
Thanks @NikitaKoksharov, which I assume means the lock isn't released when the holding process dies, but rather when the watchdog cleans it up?
– Mike Stoddart
Oct 6 '18 at 17:44
1
@MikeStoddart lock would be released automatically if watchdog won't extend it. If process dies then watchdog dies either and thus lock will be released since it wasn't extended
– Nikita Koksharov
Oct 8 '18 at 14:24
add a comment |
Linking to other answer as well for this feature in case someone else comes across. stackoverflow.com/a/21072066/311525
– Scott
Aug 26 '14 at 22:48
What happens to the lock if the holding process dies?
– Mike Stoddart
Oct 5 '18 at 16:23
1
@MikeStoddart Redisson maintains lock watchdog, it prolongs lock expiration while lock holder Redisson instance is alive.
– Nikita Koksharov
Oct 5 '18 at 16:28
Thanks @NikitaKoksharov, which I assume means the lock isn't released when the holding process dies, but rather when the watchdog cleans it up?
– Mike Stoddart
Oct 6 '18 at 17:44
1
@MikeStoddart lock would be released automatically if watchdog won't extend it. If process dies then watchdog dies either and thus lock will be released since it wasn't extended
– Nikita Koksharov
Oct 8 '18 at 14:24
Linking to other answer as well for this feature in case someone else comes across. stackoverflow.com/a/21072066/311525
– Scott
Aug 26 '14 at 22:48
Linking to other answer as well for this feature in case someone else comes across. stackoverflow.com/a/21072066/311525
– Scott
Aug 26 '14 at 22:48
What happens to the lock if the holding process dies?
– Mike Stoddart
Oct 5 '18 at 16:23
What happens to the lock if the holding process dies?
– Mike Stoddart
Oct 5 '18 at 16:23
1
1
@MikeStoddart Redisson maintains lock watchdog, it prolongs lock expiration while lock holder Redisson instance is alive.
– Nikita Koksharov
Oct 5 '18 at 16:28
@MikeStoddart Redisson maintains lock watchdog, it prolongs lock expiration while lock holder Redisson instance is alive.
– Nikita Koksharov
Oct 5 '18 at 16:28
Thanks @NikitaKoksharov, which I assume means the lock isn't released when the holding process dies, but rather when the watchdog cleans it up?
– Mike Stoddart
Oct 6 '18 at 17:44
Thanks @NikitaKoksharov, which I assume means the lock isn't released when the holding process dies, but rather when the watchdog cleans it up?
– Mike Stoddart
Oct 6 '18 at 17:44
1
1
@MikeStoddart lock would be released automatically if watchdog won't extend it. If process dies then watchdog dies either and thus lock will be released since it wasn't extended
– Nikita Koksharov
Oct 8 '18 at 14:24
@MikeStoddart lock would be released automatically if watchdog won't extend it. If process dies then watchdog dies either and thus lock will be released since it wasn't extended
– Nikita Koksharov
Oct 8 '18 at 14:24
add a comment |
You should consider using zookeeper. And there is an easy to use library for these kind of "distributed" stuff which is built on top of zookeeper : curator framework. I think what you are looking for is shared reentrant lock. You can also check other locks in recipes.
answered Apr 16 '14 at 8:42
frailfrail
3,78622234
I did not see where zookeeper provided expiring locks. I'm aware of it as a solution for distributed locks, but it didn't seem to offer the expiring feature I was looking for. If that feature does exist, can you provide a link to it as I was not able to find it.
– Scott
Apr 16 '14 at 20:19
well in zookeeper the lock would expire if the lock owner session drop which happens just like your hazelcast example. I can understand your "crash" concerns; but giving a timeout for a lock itself seems weird at best :)
– frail
Apr 16 '14 at 21:17
I get the 'crash' portion. The use case is I have many Actors locking assets. One of those actors dies, but the server still hums along. The work that actor was working on needs to go back into the pool after a period of time to avoid that work never being done. The work is idempotent, so I don't care it gets done twice, just that it gets done. I don't think this is 'weird', it has come up more than a few times as a requirement for me.
– Scott
Apr 17 '14 at 14:08
add a comment |
You should consider using zookeeper. And there is an easy to use library for these kind of "distributed" stuff which is built on top of zookeeper : curator framework. I think what you are looking for is shared reentrant lock. You can also check other locks in recipes.
answered Apr 16 '14 at 8:42
frailfrail
3,78622234
I did not see where zookeeper provided expiring locks. I'm aware of it as a solution for distributed locks, but it didn't seem to offer the expiring feature I was looking for. If that feature does exist, can you provide a link to it as I was not able to find it.
– Scott
Apr 16 '14 at 20:19
well in zookeeper the lock would expire if the lock owner session drop which happens just like your hazelcast example. I can understand your "crash" concerns; but giving a timeout for a lock itself seems weird at best :)
– frail
Apr 16 '14 at 21:17
I get the 'crash' portion. The use case is I have many Actors locking assets. One of those actors dies, but the server still hums along. The work that actor was working on needs to go back into the pool after a period of time to avoid that work never being done. The work is idempotent, so I don't care it gets done twice, just that it gets done. I don't think this is 'weird', it has come up more than a few times as a requirement for me.
– Scott
Apr 17 '14 at 14:08
add a comment |
You should consider using zookeeper. And there is an easy to use library for these kind of "distributed" stuff which is built on top of zookeeper : curator framework. I think what you are looking for is shared reentrant lock. You can also check other locks in recipes.
answered Apr 16 '14 at 8:42
frailfrail
3,78622234
You should consider using zookeeper. And there is an easy to use library for these kind of "distributed" stuff which is built on top of zookeeper : curator framework. I think what you are looking for is shared reentrant lock. You can also check other locks in recipes.
answered Apr 16 '14 at 8:42
frailfrail
3,78622234
edited Apr 16 '14 at 8:49
answered Apr 16 '14 at 8:42
frailfrail
3,78622234
answered Apr 16 '14 at 8:42
frailfrail
3,78622234
answered Apr 16 '14 at 8:42
frailfrail
3,78622234
3,78622234
I did not see where zookeeper provided expiring locks. I'm aware of it as a solution for distributed locks, but it didn't seem to offer the expiring feature I was looking for. If that feature does exist, can you provide a link to it as I was not able to find it.
– Scott
Apr 16 '14 at 20:19
well in zookeeper the lock would expire if the lock owner session drop which happens just like your hazelcast example. I can understand your "crash" concerns; but giving a timeout for a lock itself seems weird at best :)
– frail
Apr 16 '14 at 21:17
I get the 'crash' portion. The use case is I have many Actors locking assets. One of those actors dies, but the server still hums along. The work that actor was working on needs to go back into the pool after a period of time to avoid that work never being done. The work is idempotent, so I don't care it gets done twice, just that it gets done. I don't think this is 'weird', it has come up more than a few times as a requirement for me.
– Scott
Apr 17 '14 at 14:08
add a comment |
I did not see where zookeeper provided expiring locks. I'm aware of it as a solution for distributed locks, but it didn't seem to offer the expiring feature I was looking for. If that feature does exist, can you provide a link to it as I was not able to find it.
– Scott
Apr 16 '14 at 20:19
well in zookeeper the lock would expire if the lock owner session drop which happens just like your hazelcast example. I can understand your "crash" concerns; but giving a timeout for a lock itself seems weird at best :)
– frail
Apr 16 '14 at 21:17
I get the 'crash' portion. The use case is I have many Actors locking assets. One of those actors dies, but the server still hums along. The work that actor was working on needs to go back into the pool after a period of time to avoid that work never being done. The work is idempotent, so I don't care it gets done twice, just that it gets done. I don't think this is 'weird', it has come up more than a few times as a requirement for me.
– Scott
Apr 17 '14 at 14:08
I did not see where zookeeper provided expiring locks. I'm aware of it as a solution for distributed locks, but it didn't seem to offer the expiring feature I was looking for. If that feature does exist, can you provide a link to it as I was not able to find it.
– Scott
Apr 16 '14 at 20:19
I did not see where zookeeper provided expiring locks. I'm aware of it as a solution for distributed locks, but it didn't seem to offer the expiring feature I was looking for. If that feature does exist, can you provide a link to it as I was not able to find it.
– Scott
Apr 16 '14 at 20:19
well in zookeeper the lock would expire if the lock owner session drop which happens just like your hazelcast example. I can understand your "crash" concerns; but giving a timeout for a lock itself seems weird at best :)
– frail
Apr 16 '14 at 21:17
well in zookeeper the lock would expire if the lock owner session drop which happens just like your hazelcast example. I can understand your "crash" concerns; but giving a timeout for a lock itself seems weird at best :)
– frail
Apr 16 '14 at 21:17
I get the 'crash' portion. The use case is I have many Actors locking assets. One of those actors dies, but the server still hums along. The work that actor was working on needs to go back into the pool after a period of time to avoid that work never being done. The work is idempotent, so I don't care it gets done twice, just that it gets done. I don't think this is 'weird', it has come up more than a few times as a requirement for me.
– Scott
Apr 17 '14 at 14:08
I get the 'crash' portion. The use case is I have many Actors locking assets. One of those actors dies, but the server still hums along. The work that actor was working on needs to go back into the pool after a period of time to avoid that work never being done. The work is idempotent, so I don't care it gets done twice, just that it gets done. I don't think this is 'weird', it has come up more than a few times as a requirement for me.
– Scott
Apr 17 '14 at 14:08
add a comment |
What about this one?
http://www.gemstone.com/docs/5.5.0/product/docs/japi/com/gemstone/gemfire/distributed/DistributedLockService.html
Its lock method seems to have what you need:
public abstract boolean lock(Object name,
long waitTimeMillis,
long leaseTimeMillis)
Attempts to acquire a lock named name. Returns true as soon as the lock is acquired. If the lock is currently held by another thread in this or any other process in the distributed system, or another thread in the system has locked the entire service, this method keeps trying to acquire the lock for up to waitTimeMillis before giving up and returning false. If the lock is acquired, it is held until unlock(Object name) is invoked, or until leaseTimeMillis milliseconds have passed since the lock was granted - whichever comes first.
answered Apr 16 '14 at 21:20
xxaxxa
896616
add a comment |
What about this one?
http://www.gemstone.com/docs/5.5.0/product/docs/japi/com/gemstone/gemfire/distributed/DistributedLockService.html
Its lock method seems to have what you need:
public abstract boolean lock(Object name,
long waitTimeMillis,
long leaseTimeMillis)
Attempts to acquire a lock named name. Returns true as soon as the lock is acquired. If the lock is currently held by another thread in this or any other process in the distributed system, or another thread in the system has locked the entire service, this method keeps trying to acquire the lock for up to waitTimeMillis before giving up and returning false. If the lock is acquired, it is held until unlock(Object name) is invoked, or until leaseTimeMillis milliseconds have passed since the lock was granted - whichever comes first.
answered Apr 16 '14 at 21:20
xxaxxa
896616
add a comment |
What about this one?
http://www.gemstone.com/docs/5.5.0/product/docs/japi/com/gemstone/gemfire/distributed/DistributedLockService.html
Its lock method seems to have what you need:
public abstract boolean lock(Object name,
long waitTimeMillis,
long leaseTimeMillis)
Attempts to acquire a lock named name. Returns true as soon as the lock is acquired. If the lock is currently held by another thread in this or any other process in the distributed system, or another thread in the system has locked the entire service, this method keeps trying to acquire the lock for up to waitTimeMillis before giving up and returning false. If the lock is acquired, it is held until unlock(Object name) is invoked, or until leaseTimeMillis milliseconds have passed since the lock was granted - whichever comes first.
answered Apr 16 '14 at 21:20
xxaxxa
896616
What about this one?
http://www.gemstone.com/docs/5.5.0/product/docs/japi/com/gemstone/gemfire/distributed/DistributedLockService.html
Its lock method seems to have what you need:
public abstract boolean lock(Object name,
long waitTimeMillis,
long leaseTimeMillis)
Attempts to acquire a lock named name. Returns true as soon as the lock is acquired. If the lock is currently held by another thread in this or any other process in the distributed system, or another thread in the system has locked the entire service, this method keeps trying to acquire the lock for up to waitTimeMillis before giving up and returning false. If the lock is acquired, it is held until unlock(Object name) is invoked, or until leaseTimeMillis milliseconds have passed since the lock was granted - whichever comes first.
answered Apr 16 '14 at 21:20
xxaxxa
896616
answered Apr 16 '14 at 21:20
xxaxxa
896616
answered Apr 16 '14 at 21:20
xxaxxa
896616
answered Apr 16 '14 at 21:20
xxaxxa
896616
896616
add a comment |
add a comment |
Actually, as far as I can tell mongo-java-distributed-lock has the ability to expire a lock through the use of DistributedLockOptions.setInactiveLockTimeout()
I haven't tried it yet, but think I will...
EDIT: I have now also tried it, and it works well...
String lockName = "com.yourcompany.yourapplication.somelock";
int lockTimeoutMilliSeconds = 500;
String dbURI = CWConfig.get().getMongoDBConfig().getDbURI();
DistributedLockSvcFactory lockSvcFactory = new DistributedLockSvcFactory(new DistributedLockSvcOptions(dbURI));
DistributedLockSvc lockSvc = lockSvcFactory.getLockSvc();
DistributedLock lock = lockSvc.create(lockName);
lock.getOptions().setInactiveLockTimeout(lockTimeoutMilliSeconds);
try {
lock.lock();
// Do work
} finally {
lock.unlock();
}
answered May 31 '16 at 13:03
linusnlinusn
114
add a comment |
Actually, as far as I can tell mongo-java-distributed-lock has the ability to expire a lock through the use of DistributedLockOptions.setInactiveLockTimeout()
I haven't tried it yet, but think I will...
EDIT: I have now also tried it, and it works well...
String lockName = "com.yourcompany.yourapplication.somelock";
int lockTimeoutMilliSeconds = 500;
String dbURI = CWConfig.get().getMongoDBConfig().getDbURI();
DistributedLockSvcFactory lockSvcFactory = new DistributedLockSvcFactory(new DistributedLockSvcOptions(dbURI));
DistributedLockSvc lockSvc = lockSvcFactory.getLockSvc();
DistributedLock lock = lockSvc.create(lockName);
lock.getOptions().setInactiveLockTimeout(lockTimeoutMilliSeconds);
try {
lock.lock();
// Do work
} finally {
lock.unlock();
}
answered May 31 '16 at 13:03
linusnlinusn
114
add a comment |
Actually, as far as I can tell mongo-java-distributed-lock has the ability to expire a lock through the use of DistributedLockOptions.setInactiveLockTimeout()
I haven't tried it yet, but think I will...
EDIT: I have now also tried it, and it works well...
String lockName = "com.yourcompany.yourapplication.somelock";
int lockTimeoutMilliSeconds = 500;
String dbURI = CWConfig.get().getMongoDBConfig().getDbURI();
DistributedLockSvcFactory lockSvcFactory = new DistributedLockSvcFactory(new DistributedLockSvcOptions(dbURI));
DistributedLockSvc lockSvc = lockSvcFactory.getLockSvc();
DistributedLock lock = lockSvc.create(lockName);
lock.getOptions().setInactiveLockTimeout(lockTimeoutMilliSeconds);
try {
lock.lock();
// Do work
} finally {
lock.unlock();
}
answered May 31 '16 at 13:03
linusnlinusn
114
Actually, as far as I can tell mongo-java-distributed-lock has the ability to expire a lock through the use of DistributedLockOptions.setInactiveLockTimeout()
I haven't tried it yet, but think I will...
EDIT: I have now also tried it, and it works well...
String lockName = "com.yourcompany.yourapplication.somelock";
int lockTimeoutMilliSeconds = 500;
String dbURI = CWConfig.get().getMongoDBConfig().getDbURI();
DistributedLockSvcFactory lockSvcFactory = new DistributedLockSvcFactory(new DistributedLockSvcOptions(dbURI));
DistributedLockSvc lockSvc = lockSvcFactory.getLockSvc();
DistributedLock lock = lockSvc.create(lockName);
lock.getOptions().setInactiveLockTimeout(lockTimeoutMilliSeconds);
try {
lock.lock();
// Do work
} finally {
lock.unlock();
}
answered May 31 '16 at 13:03
linusnlinusn
114
edited Jun 7 '16 at 10:32
answered May 31 '16 at 13:03
linusnlinusn
114
answered May 31 '16 at 13:03
linusnlinusn
114
answered May 31 '16 at 13:03
linusnlinusn
114
114
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f22766988%2fglobal-distributed-lock-that-can-be-set-to-expire-java%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
If you're happy rolling your own then you could consider extending Lock and adding a static watcher thread that keeps a list of live locks and periodically checks expiration times.
– selig
Apr 1 '14 at 14:34
I'd love rolling my own, but also don't want to re-invent the wheel if there is a solution already out there to do this.
– Scott
Apr 1 '14 at 16:59
Possible duplicate: stackoverflow.com/questions/1059580/distributed-lock-service
– flup
Apr 14 '14 at 22:43
@flup, I'm explicitly asking for a solution that offers an expiring lock. All the other SO questions are only about distributed locks, not distributed expiring locks, the key feature I care about.
– Scott
Apr 16 '14 at 20:18