¿Compartir un bloque sincronizado de Java en un clúster o usar un bloqueo global?

Question

Tengo un código al que solo quiero permitir el acceso por un hilo. Sé cómo lograr esto utilizando bloques o métodos sincronizados , pero ¿funcionará esto en un entorno agrupado?

El entorno de destino es WebSphere 6.0, con 2 nodos en el clúster.

Tengo la sensación de que sincronizado no funcionará, ya que cada instancia de la aplicación en cada nodo tendrá su propia JVM, ¿verdad?

Lo que estoy tratando de hacer aquí es realizar algunas actualizaciones en los registros de la base de datos cuando se inicia el sistema. Buscará los registros de la base de datos que sean más antiguos que la versión del código y realizará tareas específicas para actualizarlos. Solo quiero que un nodo realice estas actualizaciones, ya que quiero asegurarme de que cada elemento de trabajo solo se actualice una vez, y el rendimiento de estas actualizaciones no es una gran preocupación, ya que solo ocurre al inicio de la aplicación, y realmente solo hace algo cuando se ha cambiado el código desde la última vez que se inició.

La base de datos es DB2v9, y estoy accediendo a ella directamente a través de JNDI (sin capa ORM).

Se ha sugerido que un bloqueo global podría ser el camino a seguir aquí, pero no estoy seguro de cómo hacerlo.

¿Alguien tiene punteros en este campo?

¡Gracias!

Answer 1

Tiene razón en que la sincronización entre procesos no funcionará utilizando las construcciones de sincronización Java. Afortunadamente, su problema no es la sincronización de código, sino la sincronización de las interacciones con la base de datos.

La forma correcta de tratar este problema es con bloqueos de nivel de base de datos. Presumiblemente, tiene alguna tabla que contiene una versión de esquema db, por lo que debe asegurarse de bloquear esa tabla durante el proceso de inicio / actualización.

Las llamadas sql / db precisas involucradas probablemente serían más claras si especificara su tipo de base de datos (DB2?) y el método de acceso (sql, jpa, etc. sin procesar).

Actualización (8/8/2009 2:39 PM) : sugiero el LOCK TABLE en alguna tabla que contiene la versión # del esquema. Esto serializará el acceso a esa tabla evitando que dos instancias se ejecuten a través del código de actualización a la vez.

Answer 2

Sí, tiene razón en que los bloques sincronizados no funcionarán en un clúster. La razón es, como usted dijo, que cada nodo tiene su propia JVM.

Sin embargo, hay formas de hacer que los bloques sincronizados funcionen en un clúster como funcionarían en un entorno de nodo único. La forma más fácil es usar un producto como Terracotta , que manejará la coordinación de hilos entre diferentes JVM para que los controles de concurrencia normales se puede usar en todo el clúster. Hay muchos artículos que explican cómo funciona esto, como Introducción a OpenTerracotta .

Hay otras soluciones, por supuesto. Depende principalmente de lo que realmente quieres lograr aquí. No necesitaría bloqueos de base de datos para sincronizar si necesita escalar, como DB no. Pero realmente le recomiendo que encuentre una solución lista para usar, porque jugar con la sincronización de clúster es un negocio desordenado :)

Answer 3

Puede usar una cuadrícula de datos en memoria como http://www.hazelcast.com/ para esto también. Esta es una estructura de datos distribuidos que admite el bloqueo.

Answer 4

Como está hablando de 2 máquinas, ni siquiera tiene memoria compartida, por lo que no hay nada que sincronizar.

Hacemos algo similar con nuestra base de datos. Esto se logra agregando versiones de registro en la tabla. Esto es lo que debes hacer,

1. Agregue una columna para la versión de registro / fila.
2. Revise la lógica para verificar si es necesario actualizar el registro.
3. Cuando actualice el registro, asegúrese de que la versión del registro en DB sea la misma que la que tiene.
4. Aumente la versión cada vez que escriba en la base de datos.

Solo debe tener un servidor que actualice la base de datos si sigue estas reglas.

Answer 5

¿No podría simplemente bloquear la tabla (o la base de datos completa) para actualizaciones, de modo que cuando el primer nodo haya obtenido el bloqueo, todos los demás nodos no podrán escribir. Los nodos posteriores esperarían, y cuando se libere el bloqueo, el código se actualizará, por lo que no se requerirá ninguna actualización de registro.