Anonymous | Login | Signup for a new account | 12-17-2024 11:31 PST |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Advanced Details [ Jump to Notes ] | [ View Simple ] [ Issue History ] [ Print ] | ||||||||
ID | Category | Severity | Reproducibility | Date Submitted | Last Update | ||||
0003464 | [Resin] | minor | always | 04-28-09 09:15 | 08-20-09 21:05 | ||||
Reporter | ferg | View Status | public | ||||||
Assigned To | ferg | ||||||||
Priority | normal | Resolution | fixed | Platform | |||||
Status | closed | OS | |||||||
Projection | none | OS Version | |||||||
ETA | none | Fixed in Version | 4.0.2 | Product Version | |||||
Product Build | |||||||||
Summary | 0003464: distributed locking | ||||||||
Description |
(rep by Martin Thompson) The semantics I'm looking for would be similar to the following code. public void onLoad() throws InterruptedException { final java.util.concurrent.locks.Lock distributedMasterLock = resinServer.getOrCreateLock("ev-master"); if (distributedMasterLock.tryLock()) { try { promoteToMaster(); // blocking } finally { distributedMasterLock.unlock(); } } else { startSecondaryBackgroundProcesses(); // non-blocking distributedMasterLock.lockInterruptibly(); try { promoteToMaster(); } finally { distributedMasterLock.unlock(); } } } Ideally the locking implementation fits the standard Lock interface and offers semantics like the above. For the secondary waiting on the lock it would be necessary that it aquires the lock almost instantly after the master has released it because of calling unlock or if it dies and just goes away without calling unlock. |
||||||||
Steps To Reproduce | |||||||||
Additional Information | |||||||||
Attached Files | |||||||||
|
Mantis 1.0.0rc3[^]
Copyright © 2000 - 2005 Mantis Group
28 total queries executed. 25 unique queries executed. |