Czy bezpieczne jest ustawienie opcji Hibernate after_transaction jako trybu zwalniania połączenia JTA podczas korzystania z Bitronix Transcation Manager?

Question

Zgodnie z Hibernate docs, w środowisku JTA domyślnym trybem zwolnienia połączenia jest after_statement, co oznacza, że ​​po każdym poleceniu zostanie zwolnione połączenie logiczne hibernacji.

Po zwolnieniu połączenia logicznego wywoływana jest metoda Connection close(), a bieżący zasób jest usuwany z listy w menedżerze transakcji.

Według RedHat'a transaction developer guide:

„Metoda delistResource wykorzystuje się do dysocjacji określonego zasobu od kontekstu transakcyjnego na obiekcie docelowym serwer aplikacji wywołuje metodę z dwoma parametrami.

An XAResources object, which represents the resource. 
A flag to indicate whether the operation is due to the transaction being suspended (TMSUSPEND), a portion of the work has failed (TMFAIL), or a normal resource release by the application (TMSUCCESS)." 

Ponieważ Bitronix używa TMSUCCESS:

currentTransaction.delistResource(xaResourceHolderState.getXAResource(), XAResource.TMSUCCESS); 

Oznacza to, że połączenie jest odłączone od bieżącego gałąź transakcji i czasami może się skończyć enlisting 2 different connections for the same Resource Adapter.

Uważam, że utrzymywanie połączenia na tyle, na ile trwa Transakcja, jest lepszym wyborem, ponieważ zwykle wykonujemy więcej niż jedno oświadczenie na transakcję. Tak więc tryb wydania after_transaction brzmi bardziej zachęcająco.

Czy tryb zwolnienia after_transaction jest bardziej odpowiedni dla Bitronix? Czy ktoś go doświadczył w środowisku produkcyjnym?

Answer 1

Nie powinieneś widzieć żadnej różnicy między after_statement i after_transaction, przynajmniej z BTM. Teoretycznie, after_statement jest "bardziej poprawne", ponieważ połączenie i transakcja mają być całkowicie niezależne w kontekście XA, a połączenie powinno obsługiwać wiele transakcji jednocześnie. W praktyce połączenia i transakcje prawie nigdy nie są niezależne, ponieważ prawie żaden zasób tego nie obsługuje.

Pula połączeń BTM implementuje relatywnie złożony moduł FSM, który pozwala mu utrzymywać transakcje izolowane na ich połączeniach, a jednocześnie w miarę możliwości ponownie używać połączenia.

W kontekście pojedynczej transakcji, wielokrotnego uzyskiwania połączenia z puli, zamknięcie go powinno zużywać tylko jedno połączenie z puli: to samo powinno być zawsze odkładane na bok przez pulę i ponownie używane. Jedynym powodem, dla którego mogę o tym pomyśleć, byłoby pobranie dwóch połączeń z puli, jeśli ponownie uzyskasz połączenie, podczas gdy pierwsza nie została jeszcze zamknięta. Każdy inny powód może być prawdopodobnie uznany za błąd w puli połączeń BTM.