Perhaps something like this already exists in the main code base (I haven't checked lately), but the idea was this: most of the problems that we were getting with locks was due to a crash of some type that left locks in place. They later had to be removed manually or the system wouldn't work. The solution that worked in our environment was to add a "staleLockAge" parameter to the methods that attempt to obtain the lock. If the lock was present but was older than the specified age, it was considered "stale" and would automatically be broken (the file deleted). This worked in our environment because we never hold locks for longer than a few minutes.
Is something like this already in the code base? If not, what do people think about it? I can supply more detailed API if needed.
Dmitry.
Scott Ganyo wrote:
Ok, I know I said I'd check in Wednesday, but as it turns out I'm going to be out Wednesday. So, as there has only been positive feedback, I'm just going to go ahead and commit now.
Scott
Scott Ganyo wrote:
As suggested in previous emails, I have implemented the ability to wait on any kind of lock. I've attached the diffs, but here are the highlights:
1) added the following statics to Lock:
public static long WRITE_LOCK_TIMEOUT = 1000; public static long COMMIT_LOCK_TIMEOUT = 10000; public static long LOCK_POLL_INTERVAL = 1000;
2) added the following method to Lock:
/** Attempt to obtain an exclusive lock within amount
* of time given. Currently polls once per second until
* lockWaitTimeout is passed.
* @param lockWaitTimeout length of time to wait in ms
* @return true if lock was obtained
* @throws IOException if lock wait times out or obtain() throws an IOException
*/
public boolean obtain(long lockWaitTimeout) throws IOException
3) added the following method to Lock.With:
/** Constructs an executor that will grab the named lock. */ public With(Lock lock, long lockWaitTimeout)
4) cleaned up Lock.With to use the new obtain(long) method on Lock.
5) changed callers obtaining "write.lock" to pass Lock.WRITE_LOCK_TIMEOUT
6) changed callers obtaining "commit.lock" to pass Lock.COMMIT_LOCK_TIMEOUT
The net effect is to expose the timeout and change the write.lock to have a 1 second timeout as a default instead of immediately throwing an IOException.
So that there can be a review and comment period, I won't plan to check it in Wednesday of next week.
Scott
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
