2012-08-20 9 views
6

Por ejemplo, tengo DBManager.java Singleton Class, que tengo que implementar en un entorno en clúster. Es una aplicación basada en web, con el siguiente despliegue stratergy¿Cómo crear una clase java singleton para soporte de múltiples jvm?

Apache Load Balancer -> Tomcat 6 (3 servidores en el clúster).

Tengo que mantener una sola instancia de DBManager para 3 instancias de tomcat.

Mi código es

package com.db.util; 
public class DBManager { 
    private static DBManager singleInstance; 
    private DBManager() {} 
    public static DBManager getSingleInstance() { 
     if (singleInstance == null) { 
      synchronized (DBManager.class) { 
       if (singleInstance == null) { 
        singleInstance = new DBManager(); 
       } 
      } 
     } 
     return singleInstance; 
    } 
} 

He estado buscando una solución a este problema, y ​​encontré algo así como API JGroups. ¿Se puede lograr esto usando JGroups? Cualquier Idea, ¿Cómo implementar eso?

+2

Si la pregunta es si puede tener un singleton en las JVM, no creo que esto sea posible. – dfb

+0

Tengo que mantener una sola instancia de DBManager para 3 instancias de tomcat. –

+0

¿Está buscando algo así como un Singleton EJB? –

Respuesta

5

Java le proporciona un singleton en cada instancia, necesita algún tipo de coordinación entre las instancias, de modo que en un momento dado una de ellas está activa, pero si la activa muere, se activa una instancia diferente.

Algunos servidores de aplicaciones tienen capacidades incorporadas para controlar tales instancias de trabajador coordinadas, no sé si Tomcat tiene dicha función.

Construir tal funcionalidad usted mismo es sorprendentemente difícil, vea this question y tenga en cuenta que esa pregunta brinda enlaces a una biblioteca útil, que a mí me parece bastante compleja de usar.

Sin embargo, en su caso tiene una base de datos, y eso le da un punto de coordinación. No he diseñado esto en detalle, pero creo que es posible crear un esquema de reservas usando una fila dedicada en una tabla de control. Será un poco complicado hacer esto de manera eficiente, equilibrando la velocidad de detección de una muerte de instancia con los gastos generales de sondear la base de datos para ver qué instancia está activa, pero parece factible.

La idea es que el registro contenga una indicación de fecha y hora "reservada" hasta "ID de proceso". Cada proceso lee el registro, si contiene su propia identificación y la marca de tiempo aún no ha expirado, sabe que puede funcionar. Cuando el tiempo casi ha expirado, el proceso activo actualiza la marca de tiempo utilizando un estilo de bloqueo optimista "Actualizar donde marca de tiempo == marca de tiempo anterior" para administrar las condiciones de carrera. Cada proceso no activo espera hasta que la marca de tiempo que leyó por última vez haya expirado y luego intenta tomar el control actualizando el registro, de nuevo usando un bloqueo optimista Actualizar donde. Por lo general, ese intento de tomar el control fracasará, pero si tiene éxito ahora tenemos una nueva instancia activa, y debido a un bloqueo optimista, solo podemos obtener una instancia activa.

+0

Vale la pena señalar que el bloqueo optimista no funciona cuando las garantías ACID no están garantizadas (por ejemplo, cuando las bases de datos se replican en los centros de datos) –

0

Singleton asegura solo una instancia de la clase en una JVM determinada.

¿Cuál es el problema con múltiples DBManagers, uno para cada JVM, en su caso?

Cuestiones relacionadas