| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: Harvey Harrison <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
SingletonInstanceFileLock error message
The getName() call here is currently calling Thread.getName() inherited by the
anonymous inner class. This is ambiguous, and likely meant to call the getName()
method of SingletonInstanceFileLock, which would output the lockfile name.
In any event, infoPrefix() is already adding the Thread name for us.
Signed-off-by: Harvey Harrison <[email protected]>
|
|
|
|
| |
start, otherwise we may collide w/ a failed start. Misc: Cleanup / reuse strings.
|
|
|
|
| |
unlock fails ; Added unit tests.
|
|
|
|
|
|
|
|
| |
- LockExt -> ThreadLock - clarifying semantics (API Change)
- ThreadLock: Remove isOwner(), use isOwner(Thread.currentThread)
- adding @Override
|
|
moved up)
We learned that FileChannel.lock() is not reliable on at least GNU/Linux + Sun's JVM implementation,
hence we need a ServerSocket implementation.
Since this code may be useful to others, it has been promoted to GlueGen.
- Abstract SingletonInstance
- Implement Lock interface
- SingletonInstance Spezialisation: FileLock and ServerSocket
Minor API Change: LockExt.isLocked() -> Lock.isLocked()
|