¿Cómo bloquear un archivo en diferentes niveles de aplicación?

Este es el escenario: tengo una aplicación web Java multihilo que se ejecuta dentro de un contenedor de servlets. La aplicación se implementa varias veces dentro del contenedor de servlet. Hay múltiples contenedores de servlets que se ejecutan en diferentes servidores.

Quizás este gráfico lo deja claro:

server1
+- servlet container
   +- application1
   |  +- thread1
   |  +- thread2
   +- application2
      +- thread1
      +- thread2
server2
+- servlet container
   +- application1
   |  +- thread1
   |  +- thread2
   +- application2
      +- thread1
      +- thread2

Hay un archivo dentro de un directorio compartido de red al que pueden acceder todos esos hilos. Y acceden al archivo con frecuencia. La mayoría de las veces el archivo solo es leído por esos hilos. Pero a veces está escrito.

Necesito una solución a prueba de fallos para sincronizar todos esos subprocesos para garantizar la coherencia de los datos.

Soluciones que no funcionan (correctamente):

Usando java.nio.channels.FileLock
Puedo sincronizar hilos de diferentes servidores usando la clase FileLock. Pero esto no funciona para hilos dentro del mismo proceso (contenedor de servlet) ya que los bloqueos de archivos están disponibles en todo el proceso.

Usando un archivo separado para la sincronización
Podría crear un archivo separado que indica que un proceso está leyendo o escribiendo en el archivo. Esta solución funciona para todos los subprocesos pero tiene varios inconvenientes:

Actuación. Crear, eliminar y verificar archivos son operaciones bastante lentas. Las implementaciones de bajo peso con un archivo de sincronización evitarán la lectura paralela del archivo.El archivo de sincronización permanecerá después de un bloqueo de JVM que hace necesaria una limpieza manual.Ya hemos tenido problemas extraños al eliminar archivos en sistemas de archivos de red.

Usando mensajes
Podríamos implementar un sistema de mensajería que los hilos usarían para coordinar el acceso al archivo. Pero esto parece demasiado complejo para este problema. Y de nuevo: el rendimiento será pobre.

¿Alguna idea?

Respuestas a la pregunta(6)

Su respuesta a la pregunta