Логическа единица работа и отделна единица работа в 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 нишки няма да работят върху него точно по едно и също време.

Сесията не е безопасна за нишки и представлява единица работа с една нишка.

Дали след сесийна фабрика множество сесии (в сесийна фабрика) ще се развиват, всяка от които обхваща собствената си работа в собствената си единична нишка?


person Farhan Shirgill Ansari    schedule 17.11.2014    source източник


Отговори (1)


SessionFactory е безопасен за нишки и имате единична Sessionfactory за даден DataSource.

Сесиите могат да или да бъдат създадени за живота на една заявка или дори да бъдат удължени за обхващане на множество потребителски заявки.

Сесията винаги трябва да бъде обвързана с една нишка във всеки даден момент. Дори когато използвате разширен контекст на постоянство, има само една заявка/нишка за достъп до сесията в даден момент.

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

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

Като цяло, сесията не е безопасна, заедно с всичките й прикачени единици. Фабриката за сесии е безопасна за нишки, защото получавате само един екземпляр с един елемент на DataSource и го използвате за създаване на нови сесии.

person Vlad Mihalcea    schedule 17.11.2014