Дело в том, что гарантии блокировки файла дает (или НЕ дает), собственно, файловая система, а Ява просто довольствуется тем, что есть. Существует две принципиально разные идеологии: либо блокировка ФС таки блокирует (как в Винде), либо она носит скорее информативно-предупреждающий характер (как в Линуксе). Обе - со своими плюсами и минусами.
В Яве есть механизм доступа к этому делу, в
java.nio.channels.FileLock, но что и как с его помощю удастся реализовать, прямо зависит от платформы.
В связи с этим, для решения указанной задачи существует два подхода.
Кривой, исторически-обусловленный, используется, например, в HL7 (где проблема интероперабельности разных платформ через ФС все еще актуальна) определена иная семантика семафорных файлов: семафорный файл создается ПОСЛЕ того, как файл данных освобожден пишущим процессом (т.е. наличие семафора является гарантией ОТСУТСТВИЯ блокировки). Это элементарно реализуется на Яве созданием семафорного файла во временной папке с последующим move в целевую, ибо атомарность move-а гарантируется ФС. Недостаток этого подхода в том, что на однажды освобожденный файл нельзя повторно получить блокировку, в связи с чем вся эта костыльная кухня практически не масштабируется.
Правильное, более универсальное и масштабируемое решение - вообще не использовать ФС в качестве shared memory (которая для этого, строго говоря, и не предназначена), а соединять процессы через брокер с внятным протоколом (очередь сообщений, сокеты, БД в конце концов).
Так что, если это возможно, рекомендую попытаться решить проблему на уровне переосмысления общей архитектуры системы. Если нет, то придется клепать свой платформозависимый велосипед из
java.nio.* и
java.util.concurrent.* (например
ReentrantLock)... т.е., фактически, переизобретать эдак добрую треть JEE :)
P.S. Кстати, если это чудо должно еще и поверх smb крутиться, то я бы, лично, лучше сразу завернулся в простыню и пополз на кладбище, т.к. от smb с сетью в этом деле можно поиметь под нагрузкой еще как минимум столько же удовольствия.
