Логическая единица работы и единая единица работы в JPA, JTA

Я часто встречал эти термины. Есть ли разница между ними ч/б?

В следующем фрагменте кода Java метод является потокобезопасным:

class Counter {
    private int i = 0;

    public synchronized void inc() {
        i++;
    }
}

В контексте SessionFactory и Session в Hibernate тогда

SessionFactory (org.hibernate.SessionFactory) - A thread-safe

Session (org.hibernate.Session) - A single-threaded, short-lived object representing a   
conversation between the application and the persistent store.

Я путаюсь здесь в понимании их определения.

Все, что я понимаю, это то, что поскольку SessionFactory является поточно-безопасным, любой поток сначала должен получить блокировку, а затем будет работать над этим, т. е. реализация гарантированно будет свободна от условий гонки при одновременном доступе нескольких потоков. (Обратите внимание, я написал одновременно, а не параллельно). После того, как один поток завершит свою работу, другой поток в очереди получит блокировку, и так далее. Никакие 2 потока не будут работать над ним точно в одно и то же время.

Сеанс не является потокобезопасным и представляет собой однопотоковую единицу работы. >.

Дело в том, что после сеансовой фабрики несколько сеансов (в сеансовой фабрике) будут развиваться, каждый из которых будет выполнять свою работу в своем собственном однопоточном режиме?


java hibernate transactions jpa jta
person Farhan Shirgill Ansari    schedule 17.11.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

SessionFactory является потокобезопасным, и у вас есть одноэлементная Sessionfactory для данного источника данных.

Сеансы могут создаваться на время действия одного запроса или даже расширяться. для охвата нескольких пользовательских запросов.

Сессия всегда должна быть привязана к одному потоку в любой момент времени. Даже когда вы используете расширенный контекст сохраняемости, это только один запрос/поток для доступа к сеансу в определенный момент времени.

Таким образом, сеанс не должен быть доступен одновременно. Вот почему вам не нужно синхронизировать свои объекты, по крайней мере, не с точки зрения Hibernate. Каждая сессия загружает свою собственную копию объекта, и параллелизм обычно обеспечивается с помощью оптимистическая блокировка, поскольку желательно иметь повторяемые операции чтения на уровне приложения.

Таким образом, объекты не должны быть синхронизированы. Управление параллелизмом происходит внутри базы данных, а не в логике вашего приложения. Каждый клиентский запрос всегда будет выдавать операторы DML в рамках транзакции физической базы данных и транзакции базы данных всегда блокируются при изменении строк (даже для READ_COMMITTED).

В целом, сеанс не является безопасным для протектора вместе со всеми присоединенными к нему сущностями. Фабрика сеансов является потокобезопасной, поскольку вы получаете только один экземпляр singleton для каждого источника данных и используете его для создания новых сеансов.

person Vlad Mihalcea    schedule 17.11.2014