Class FileLockManagerTest
java.lang.Object
ubic.gemma.core.util.locking.FileLockManagerTest
-
Constructor Summary
Constructors -
Method Summary
Modifier and TypeMethodDescriptionvoidtearDown()voidvoidA degraded shared lock upgrades into a real one:toExclusive()re-acquires from scratch, which is how a probe that decides to write still coordinates properly.voidThe counterpart: an exclusive acquirer still gets its directory chain.voidvoidThe path→lock mapping must survive as long as any holder does — regardless of WHICHPathinstance each caller used and of what the garbage collector decides.voidvoidOnce the directory exists a writer can be mid-copy into it, so the real file lock comes back and reader/writer coordination is what it always was.void🛑 A shared lock is often taken only to ask "does this file exist?", and it must not answer by creating the directory the file would have lived in.voidA read-only directory is a read-only directory, not an error.voidvoidvoidvoidvoid
-
Constructor Details
-
FileLockManagerTest
public FileLockManagerTest()
-
-
Method Details
-
tearDown
- Throws:
IOException
-
testMappingSurvivesTheFirstAcquirersKeyBeingCollected
The path→lock mapping must survive as long as any holder does — regardless of WHICHPathinstance each caller used and of what the garbage collector decides.The JVM's file-lock table is global, so two
ReadWriteFileLockinstances for one file throwOverlappingFileLockExceptionthe moment both lock. The manager once kept the mapping in aWeakHashMap, where the entry was reachable only through the FIRST acquirer's key object: a cache probe would create the entry and close, a later caller would hold the lock through an equal-but-distinctPath, GC would evict the entry mid-hold, and the next probe would mint a second instance against the held file — observed as every/data/rawrequest 500ing instantly while a disconnected caller's build still held the exclusive lock (2026-08-19). TheSystem.gc()calls below made that reproduce; with a strong map they must be irrelevant.- Throws:
Exception
-
testExclusiveLockStillCreatesItsDirectoryChain
The counterpart: an exclusive acquirer still gets its directory chain.copyMetadataFileInternaltakes the lock BEFORE creating the parent directories, so removing this would break every metadata write.- Throws:
IOException
-
testGetLockInfo
- Throws:
IOException
-
testReentrant
- Throws:
IOException
-
testToExclusive
- Throws:
IOException
-
testSteal
- Throws:
IOException
-
testStealWithPath
- Throws:
IOException
-
testConcurrent
- Throws:
IOExceptionInterruptedException
-
testTwoManagers
- Throws:
IOException
-