Como os métodos estáticos sincronizados funcionam em Java e posso usá-lo para carregar entidades do Hibernate?

Se eu tiver uma classe util com métodos estáticos que chamarão as funções do Hibernate para obter acesso básico aos dados. Eu estou querendo saber se fazer o método synchronizedé a abordagem correta para garantir a segurança do thread.

Quero que isso impeça o acesso de informações à mesma instância de banco de dados. No entanto, agora tenho certeza se o código a seguir está impedindo getObjectByIda chamada para todas as classes quando é chamado por uma classe específica.

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
}

Usando sincronizado em um bloqueio de método estático, você sincronizará os métodos e atributos da classe (em oposição aos métodos e atributos da instância)

Portanto, sua suposição está correta.

Gostaria de saber se tornar o método sincronizado é a abordagem correta para garantir a segurança do thread.

Na verdade não. Você deve deixar seu RDBMS fazer esse trabalho. Eles são bons nesse tipo de coisa.

A única coisa que você conseguirá sincronizando o acesso ao banco de dados é tornar seu aplicativo terrivelmente lento. Além disso, no código que você postou, você está construindo um Session Factory toda vez, dessa forma, seu aplicativo passará mais tempo acessando o banco de dados do que realizando o trabalho real.

Imagine o seguinte cenário:

Os clientes A e B tentam inserir informações diferentes no registro X da tabela T.

Com sua abordagem, a única coisa que você obtém é garantir que uma seja chamada após a outra, quando isso aconteceria de qualquer maneira no banco de dados, porque o RDBMS os impedirá de inserir meia informação de A e metade de B ao mesmo tempo . O resultado será o mesmo, mas apenas 5 vezes (ou mais) mais lento.

Provavelmente, seria melhor dar uma olhada no capítulo "Transações e simultaneidade" na documentação do Hibernate. Na maioria das vezes, os problemas que você está tentando resolver já foram resolvidos e de uma maneira muito melhor.

Para abordar a questão de maneira mais geral ...

Lembre-se de que o uso de métodos sincronizados é realmente apenas uma abreviação (suponha que a classe seja SomeClass):

synchronized static void foo() {
    ...
}

é o mesmo que

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

e

synchronized void foo() {
    ...
}

é o mesmo que

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

Você pode usar qualquer objeto como a trava. Se você deseja bloquear subconjuntos de métodos estáticos, pode

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 não estáticos, você gostaria que os bloqueios fossem campos não estáticos)

Os métodos estáticos usam a classe como objeto de bloqueio, que é Utils.class no seu exemplo. Então sim, está tudo bem.

static synchronizedsignifica segurar a trava no Classobjeto da classe, onde synchronized significa segurar a trava no próprio objeto da classe. Isso significa que, se você estiver acessando um método sincronizado não estático em um encadeamento (de execução), ainda poderá acessar um método sincronizado estático usando outro encadeamento.

Portanto, não é possível acessar dois mesmos tipos de métodos (dois métodos estáticos ou dois métodos não estáticos) a qualquer momento por mais de um encadeamento.

Por que você deseja impor que apenas um único encadeamento possa acessar o banco de dados a qualquer momento?

É tarefa do driver do banco de dados implementar qualquer bloqueio necessário, assumindo umaConnection seja usada apenas por um encadeamento de cada vez!

Provavelmente, seu banco de dados é perfeitamente capaz de lidar com vários acessos paralelos

Se tem algo a ver com os dados do seu banco de dados, por que não utilizar o bloqueio de isolamento do banco de dados para obter isso?

Para responder à sua pergunta, sim: ele não synchronizedpode ser executado por mais de um thread por vez.

Como a synchronizedpalavra-chave Java funciona

Quando você adiciona a synchronizedpalavra-chave a um método estático, o método pode ser chamado apenas por um único thread por vez.

No seu caso, toda chamada de método irá:

• crie um novo SessionFactory
• crie um novo Session
• buscar a entidade
• retornar a entidade de volta para o chamador

No entanto, esses eram seus requisitos:

• Quero que isso impeça o acesso a informações na mesma instância do banco de dados.
• impedindo de getObjectByIdser chamado para todas as classes quando é chamado por uma classe específica

Portanto, mesmo que o getObjectByIdmétodo seja seguro para threads, a implementação está errada.

SessionFactory Melhores Práticas

O SessionFactorythread é seguro e é um objeto muito caro para criar, pois precisa analisar as classes de entidade e criar a representação interna do metamodelo da entidade.

Portanto, você não deve criar a chamada SessionFactorya cada getObjectByIdmétodo.

Em vez disso, você deve criar uma instância singleton para ela.

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

O Sessiondeve sempre estar fechado

Você não fechar o Sessionem umfinally bloco, e isso pode vazar recursos de banco de dados se uma exceção é lançada quando o carregamento da entidade.

De acordo com o Session.loadmétodo, o JavaDoc pode lançar a HibernateExceptionse a entidade não puder ser encontrada no banco de dados.

Você não deve usar esse método para determinar se existe uma instância (use em get()vez disso). Use isso apenas para recuperar uma instância que você supõe existir, onde a inexistência seria um erro real.

É por isso que você precisa usar um finallybloco para fechar o Sessionseguinte:

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(); 
         }
     }
 }

Impedindo o acesso multithread

No seu caso, você queria garantir que apenas um encadeamento tenha acesso a essa entidade específica.

Mas a synchronizedpalavra - chave impede apenas que dois threads chamem ogetObjectById concorrente. Se os dois threads chamarem esse método um após o outro, você ainda terá dois threads usando essa entidade.

Portanto, se você deseja bloquear um determinado objeto de banco de dados para que nenhum outro encadeamento possa modificá-lo, será necessário usar bloqueios de banco de dados.

A synchronizedpalavra-chave funciona apenas em uma única JVM. Se você tiver vários nós da web, isso não impedirá o acesso multiencadeado em várias JVMs.

O que você precisa fazer é usar LockModeType.PESSIMISTIC_READouLockModeType.PESSIMISTIC_WRITE ao aplicar as alterações no banco de dados, assim:

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(); 
    }
}

Então, foi o que eu fiz:

• Criei um novo EntityTransactione iniciei uma nova transação de banco de dados
• Carreguei a Postentidade enquanto mantinha um bloqueio no registro do banco de dados associado
• Mudei a Postentidade e comprometi a transação
• No caso de um Exceptionser jogado, reverti a transação

Para obter mais detalhes sobre transações ACID e banco de dados, consulte este artigo também.