Terminy "jta-datasource" i "resouce-local datasource" są dla mnie trochę niejasne.
Zgaduję, że faktycznie odnoszą się do elementów jta-datasource i non-jta-datasource. W skrócie:
- jeśli typ transakcji jednostki utrwalania jest JTA element
jta-datasource służy do deklarowania nazwy JNDI źródła danych JTA, który zostanie użyty w celu uzyskania połączenia. Jest to powszechny przypadek.
- Jeśli typ transakcji jednostki utrwalania to resource-local, należy użyć deklaracji nazwy JNDI źródła danych innego niż JTA.
- tej samej bazy danych można określić jako JTA-źródła danych lub jako zasobu lokalnego źródła danych
ta jest poprawna. I nie wspomniałem o tym powyżej, ale niektórzy dostawcy zezwalają nawet na deklarowanie zarówno jta-datasource, jak i późniejszego wykorzystania zoptymalizowanego odczytu przez połączenia inne niż JTA (tj. Które nie będą powiązane z trwającą transakcją JTA) .
- Jeśli wymieniany jako JTA-źródła danych, a następnie ziarna/inne klasy mogą korzystać JTA. Stąd interfejs UserTransaction.
Pierwsza część jest poprawna, ostatnia część nie do końca. Od specyfikacji EJB 3.0, rozdział 13.3.4 Fasola Przedsiębiorstwo Korzystanie Container-Managed rozgraniczenie transakcja:
metody handlu Przedsiębiorstwo Fasoli [...] nie może próbować uzyskać lub użyć interfejsu javax.transaction.UserTransaction.
I sekcja 16,12 UserTransaction Interfejs:
Pojemnik nie musi uczynić interfejs UserTransaction dostępny do ziaren przedsiębiorstw, które nie mogą korzystać z tego interfejsu.
Innymi słowy, interfejs UserTransaction nie jest dostępny dla komponentów biznesowych CMT.
- Nie można użyć CMT/BMT jeśli źródło danych jest zasób lokalny
Brzmienie jest nieco mylące tutaj, ale powiedziałbym, że to nie jest to bezwzględnie poprawne. Z 1.0 specyfikacji JPA, sekcja § 5.5 kontrolowania transakcji:
Zarządca jednostka aplikacja zarządzane mogą być albo kierownik podmiotu JTA lub menedżerem jednostka zasobów lokalnych.
...
Zarówno JTA podmiot zarządzający i menedżerowie są wymagane jednostka zasobu lokalnego, które będą wspierane w pojemnikach internetowych Java EE i kontenerów EJB. W środowisku EJB zwykle używany jest menedżer encji JTA.
I sekcja 6.2.1.2 transakcja typu
Atrybut transaction-type służy do określenia, czy podmiot zarządzający dostarczone przez fabrykę kierownika jednostki za jednostkę trwałości musi być podmiot zarządzający JTA lub zasobu -local podmioty zarządzające. Wartość tego elementu to JTA lub RESOURCE_LOCAL. Typ transakcji JTA zakłada, że źródło danych JTA zostanie dostarczone - albo określone przez element jta-data-source lub dostarczone przez kontener. Ogólnie, w środowisku Java EE, transaction-type z RESOURCE_LOCAL zakłada, że dostarczone zostanie źródło danych inne niż JTA. W środowisku Java EE, jeśli ten element nie jest określony, wartością domyślną jest JTA.
dzięki czemu można korzystać z aplikacji zarządzanych kierownik podmiotu który może być zasób lokalny menedżer jednostka (trzeba wstrzykiwania EntityManagerFactory uzyskać EM z nim w tym przypadku) i nie będzie część transakcji JTA. Zobacz this (very interesting) discussion.
- Jeśli wymieniany jako zasobu lokalnego źródła danych, transakcji JTA nie są świadomi. Kod można wykorzystać interfejs EntityTransaction ale nie interfejs UserTransaction
Ponownie, brzmienie jest nieco mylące, ale powiedziałbym, że jest to poprawne.
Witam, Dziękuję bardzo za poświęcenie czasu i wyjaśnienie tego wszystkiego tak jasno! Teraz widzę, że używamy terminu "resource local EntityManager", a nie "resource local datasource". Tak, miałem na myśli non-jta-datasource, kiedy powiedziałem "resource local datasource". Oto, jak rozumiem teraz: JTA/RESOURCE_LOCAL -> Typ transakcji EntityManager. Określa, kto kontroluje transakcję bazową. czy JTA/EntityTransaction API JTA EntityManger: Kontener zarządza tym EntityManager. Uczestniczy w transakcjach JTA. Transakcja JTA może być CMT lub BMT. Może być stosowany w klasach zarządzanych. – stratwine
Menedżer zasobów Local Local: EnityManager nie jest zarządzany przez kontener. Dotyczy transakcji innych niż transakcje JTA. Interfejs API EntityTransaction jest używany. można używać w POJOs Dla BMT, UserTransaction zawsze używa JTA-źródła danych i nie można używać non-JTA-źródło danych dla CMT Podobnie też, pojemnik może wykorzystać tylko JTA-źródło danych – stratwine
@stratwine: jesteś mile widziany , cieszę się, że okazało się to pomocne (a twoje zrozumienie wygląda poprawnie). Jeśli chodzi o sformułowanie, nie chciałem być wybredny, ale ponieważ specyfik definiuje bardzo precyzyjną (i subtelną) terminologię, używanie go ułatwia komunikację, i dlatego nalegałem trochę na ten temat (i polecam przeczytać części, które zacytowałem częściowo). –