How to use java to implement a file lock on the file system, for use in multi-threaded code?

Question

Java

Problem:
Interaction with the external system is carried out through the file system (smb).
There is a folder on the file system where you need to write files, then OUTBOX . To synchronize access to OUTBOX, a file is used - a semaphore (hereinafter - semFile ).
Writers (we), in order to write a file to OUTBOX, must acquire a lock on the file semFile .
Readers (external system) to read must acquire a lock on the file semFile .
The number of writers is not known in advance. Recording is carried out at an arbitrary time, multi-threaded and quite often.
Reading takes place at random times.
If the file lock is already taken by one thread, other threads should not try to acquire this lock, but write to OUTBOX immediately .
The lock cannot be released until all writers have finished writing files to the OUTBOX .
Restriction - java 6.
Actually the question is:
Tell me, are there any libraries with the implementation of the necessary functionality or at least similar to it?
Has anyone written similar things and can share their experience (I'm new to concurrency) ?
If you still have to write your own bike, please tell me where to look.
Thank you.

Answer 1

The fact is that the file system itself gives (or does NOT give) guarantees for blocking the file, and Java is simply content with what it has. There are two fundamentally different ideologies: either the blocking of the FS still blocks (as in Windows), or it is more of an informative and warning character (as in Linux). Both - with their pluses and minuses.
Java has a mechanism for accessing this case, in java.nio.channels.FileLock , but what and how it can be implemented with its help depends directly on the platform.
In this regard, there are two approaches to solve this problem.
The curve, historically determined, is used, for example, in HL7 (where the problem of interoperability of different platforms through the FS is still relevant), a different semantics of semaphore files is defined: the semaphore file is created AFTER the data file is freed by the writing process (i.e. the presence of a semaphore is NO blockage guarantee). This is elementary implemented in Java by creating a semaphore file in a temporary folder, followed by move to the target one, because the atomicity of move is guaranteed by the FS. The disadvantage of this approach is that once a file is freed, it is impossible to get a lock again, and therefore all this hack kitchen is practically not scalable.
The correct, more universal and scalable solution is not to use the FS as shared memory at all (which, strictly speaking, is not intended for this), but to connect processes through a broker with a clear protocol (message queue, sockets, database after all).
So, if possible, I recommend trying to solve the problem at the level of rethinking the overall system architecture. If not, then you will have to rivet your own platform-specific bicycle from java.nio.* and java.util.concurrent.* (for example , ReentrantLock ) ... i.e., in fact, re-invent a good third of JEE in this way :)
PS By the way, if this miracle should also spin on top of smb, then I, personally, would better immediately wrap myself in a sheet and crawl to the cemetery, tk. from smb with a network in this case, you can have at least the same amount of pleasure under load.

Answer 2

No way. Samba will not give guarantees for blocking.
Need a reliable system with FS interface - use zookerper

Answer 3

The lock cannot be released until all writers have finished writing files to the OUTBOX

IMHO, based on this condition, the turn of writers suggests itself ..