¿Cómo funcionan los métodos estáticos sincronizados en Java y puedo usarlos para cargar entidades de Hibernate?

Si tengo una clase util con métodos estáticos que llamarán a las funciones de Hibernate para lograr el acceso básico a datos. Me pregunto si hacer el método synchronizedes el enfoque correcto para garantizar la seguridad del hilo.

Quiero que esto evite el acceso de información a la misma instancia de DB. Sin embargo, ahora estoy seguro de si el siguiente código impide que getObjectByIdse invoque para todas las clases cuando una clase en particular lo invoca.

public class Utils {
     public static synchronized Object getObjectById (Class objclass, Long id) {
           // call hibernate class
         Session session = new Configuration().configure().buildSessionFactory().openSession();
         Object obj = session.load(objclass, id);
         session.close();
         return obj;
     }

     // other static methods
}

Al usar sincronizado en un bloqueo de método estático, sincronizará los métodos y atributos de clase (en oposición a los métodos y atributos de instancia)

Entonces su suposición es correcta.

Me pregunto si hacer que el método esté sincronizado es el enfoque correcto para garantizar la seguridad del hilo.

Realmente no. Debería dejar que su RDBMS haga ese trabajo en su lugar. Son buenos en este tipo de cosas.

Lo único que obtendrá al sincronizar el acceso a la base de datos es hacer que su aplicación sea terriblemente lenta. Además, en el código que publicó está creando una Fábrica de sesiones cada vez, de esa manera, su aplicación pasará más tiempo accediendo a la base de datos que realizando el trabajo real.

Imagine el siguiente escenario:

Los clientes A y B intentan insertar información diferente en el registro X de la tabla T.

Con su enfoque, lo único que está obteniendo es asegurarse de que se llame uno después del otro, cuando esto sucedería de todos modos en la base de datos, porque el RDBMS les impedirá insertar la mitad de la información de A y la otra mitad de B al mismo tiempo . El resultado será el mismo pero solo 5 veces (o más) más lento.

Probablemente sería mejor echar un vistazo al capítulo "Transacciones y concurrencia" en la documentación de Hibernate. La mayoría de las veces, los problemas que intenta resolver ya se han resuelto y de una manera mucho mejor.

Para abordar la pregunta de manera más general ...

Tenga en cuenta que usar métodos sincronizados en realidad es solo una forma abreviada (suponga que la clase es SomeClass):

synchronized static void foo() {
    ...
}

es lo mismo que

static void foo() {
    synchronized(SomeClass.class) {
        ...
    }
}

y

synchronized void foo() {
    ...
}

es lo mismo que

void foo() {
    synchronized(this) {
        ...
    }
}

Puede usar cualquier objeto como cerradura. Si desea bloquear subconjuntos de métodos estáticos, puede

class SomeClass {
    private static final Object LOCK_1 = new Object() {};
    private static final Object LOCK_2 = new Object() {};
    static void foo() {
        synchronized(LOCK_1) {...}
    }
    static void fee() {
        synchronized(LOCK_1) {...}
    }
    static void fie() {
        synchronized(LOCK_2) {...}
    }
    static void fo() {
        synchronized(LOCK_2) {...}
    }
}

(para métodos no estáticos, querrá hacer que los bloqueos sean campos no estáticos)

Los métodos estáticos usan la clase como el objeto para el bloqueo, que es Utils.class para su ejemplo. Entonces sí, está bien.

static synchronizedsignifica mantener el bloqueo en el Classobjeto de la clase donde como synchronized significa mantener el bloqueo en el objeto de esa clase. Eso significa que si está accediendo a un método sincronizado no estático en un hilo (de ejecución) aún puede acceder a un método sincronizado estático usando otro hilo.

Por lo tanto, acceder a dos métodos del mismo tipo (ya sea dos métodos estáticos o dos no estáticos) en cualquier momento por más de un hilo no es posible.

¿Por qué quiere exigir que solo un subproceso pueda acceder a la base de datos al mismo tiempo?

Es el trabajo del controlador de la base de datos implementar cualquier bloqueo necesario, suponiendo queConnection que solo se use un subproceso a la vez!

Lo más probable es que su base de datos sea perfectamente capaz de manejar múltiples accesos paralelos

Si tiene que ver con los datos de su base de datos, ¿por qué no utilizar el bloqueo de aislamiento de la base de datos para lograrlo?

Para responder a su pregunta, sí: su synchronizedmétodo no puede ser ejecutado por más de un hilo a la vez.

Cómo funciona la synchronizedpalabra clave Java

Cuando agrega la synchronizedpalabra clave a un método estático, el método solo puede ser llamado por un solo hilo a la vez.

En su caso, cada llamada al método:

• crear un nuevo SessionFactory
• crear un nuevo Session
• buscar la entidad
• devolver la entidad a la persona que llama

Sin embargo, estos fueron sus requisitos:

• Quiero que esto evite el acceso a la información a la misma instancia de DB.
• evitar que getObjectByIdse llame para todas las clases cuando una clase particular lo llama

Entonces, incluso si el getObjectByIdmétodo es seguro para subprocesos, la implementación es incorrecta.

SessionFactory mejores prácticas

El SessionFactoryes seguro para subprocesos, y es un objeto muy costoso crear, ya que necesita para analizar las clases de entidad y construir la representación interna entidad metamodelo.

Por lo tanto, no debe crear la llamada SessionFactorya cada getObjectByIdmétodo.

En su lugar, debe crear una instancia singleton para ello.

private static final SessionFactory sessionFactory = new Configuration()
    .configure()
    .buildSessionFactory();

El Sessionsiempre debe estar cerrado

No cerró el Sessionen un finallybloque, y esto puede filtrar recursos de la base de datos si se produce una excepción al cargar la entidad.

Según el Session.loadmétodo, JavaDoc podría arrojar un HibernateExceptionsi la entidad no se puede encontrar en la base de datos.

No debe usar este método para determinar si existe una instancia (use get()en su lugar). Use esto solo para recuperar una instancia que usted supone que existe, donde la inexistencia sería un error real.

Es por eso que necesita usar un finallybloque para cerrar Session, como este:

public static synchronized Object getObjectById (Class objclass, Long id) {    
     Session session = null;
     try {
         session = sessionFactory.openSession();
         return session.load(objclass, id);
     } finally {
         if(session != null) {
             session.close(); 
         }
     }
 }

Prevención de acceso multihilo

En su caso, quería asegurarse de que solo un hilo tenga acceso a esa entidad en particular.

Pero la synchronizedpalabra clave solo evita que dos hilos llamen al getObjectByIdmismo tiempo. Si los dos hilos llaman a este método uno después del otro, aún tendrá dos hilos usando esta entidad.

Entonces, si desea bloquear un objeto de base de datos dado para que ningún otro hilo pueda modificarlo, entonces necesita usar bloqueos de base de datos.

La synchronizedpalabra clave solo funciona en una sola JVM. Si tiene varios nodos web, esto no impedirá el acceso de subprocesos múltiples en varias JVM.

Lo que debe hacer es usar LockModeType.PESSIMISTIC_READoLockModeType.PESSIMISTIC_WRITE aplicar los cambios a la base de datos, de esta manera:

Session session = null;
EntityTransaction tx = null;

try {
    session = sessionFactory.openSession();

    tx = session.getTransaction();
    tx.begin();

    Post post = session.find(
        Post.class, 
        id, 
        LockModeType.LockModeType.PESSIMISTIC_READ
    );

    post.setTitle("High-Performance Java Perisstence");

    tx.commit();
} catch(Exception e) {
    LOGGER.error("Post entity could not be changed", e);
    if(tx != null) {
        tx.rollback(); 
    }
} finally {
    if(session != null) {
        session.close(); 
    }
}

Entonces, esto es lo que hice:

• Creé una nueva EntityTransactiony comencé una nueva transacción de base de datos
• Cargué la Postentidad mientras mantenía un bloqueo en el registro de la base de datos asociada
• Cambié la Postentidad y comprometí la transacción.
• En caso de Exceptionser arrojado, revertí la transacción

Para obtener más detalles sobre ACID y las transacciones de la base de datos, consulte también este artículo .