Konsekwencje stosowanie RESOURCE_LOCAL na serwerze aplikacyjnym w JPA

Witam,
Ostatnio dłubię trochę w aplikacji bazodanowej, w której, ku mojemu zdziwieniu, na serwerze aplikacyjnym transakcje obsługiwane są ręcznie (commit / rollback), za pomocą RESOURCE_LOCAL, z użyciem fabryk entity managerow. Rozwiazanie dziala, ale troche mnie dziwi: ja uzylbym JTA i zdal sie na kontener.

W internecie pisza generalnie, zeby nigdy nie obslugiwac transakcji w ten sposob, do tego sluzy kontener JTA/EJB. Zastanawiam sie jakie sa ewentualne korzysci z kosztownej migracji do JTA (w tej chwili serwer to Glassfish v4, kiedys Glassfish v2). Migracja wiazalaby sie z przerobieniem duzej ilosci kodu.

Jakie sa potencjalne korzysci z takiego pomyslu?

Pozdrawiam,

I najwazniejsze: czy grozi mi cos jesli wciaz rozwijana aplikacja zostanie przez RESOURCE_LOCAL poza tym, ze nie wykorzystuje w pelni mozliwosci serwera aplikacji? Aktualnie jest to slabe, ale dziala. A ruszanie kodu, ktory dziala moze potencjalnie to zepsuc. No i rozwazam plusy i minusy.

Masz napisane testy do tego kodu? Jak masz to zmień to na JTA, jak nie masz to napisz testy i zmień to na JTA.

Inna sprawa, że trzeba by dokładnie przyjrzeć się temu co obejmują transakcje i czy przez przypadek nie ma tam, poza logiką utrwalania danych w spójny sposób, jakiejś głębszej logiki biznesowej.

Podstawowe pytanie: macie rozproszone transakcje? Jest mozliwosc ze bedziecie rozproszone potrzebowac? Mam tutaj na mysli ze w jednej tx jest baza danych i jakas inna, i moze jeszcze cos innego, jak MDB.
Jesli macie tak juz teraz i uzywacie RESOURCE_LOCAL, to lipa na maksa.
Jesli nie i nie ma potrzeby na rozproszone tx, to bym zostawil jak jest skoro dziala. Nie wiem nic na temat testow, czy je macie, ile, co to za aplikacja, ale zasada jest 'nie tykaj gowna bo bedzie smierdziec' - mozesz za duzo zepsuc i moze cie to kosztowac duzo pracy.
Jesli nia macie rozproszonych tx ale bedziecie miec, to lepiej przesiasc sie juz teraz niz pozniej, gdy kodu bedzie wiecej.
Moje 2 grosze.

Dziekuje za zainteresowanie. Testow oczywiscie nie ma. Bedzie okazja nauczyc sie je pisac. Nie wiem na czym polegaja transakcje rozproszone (z tego co czytalem dotycza one wielu serwerow), ale po czesci logika biznesowa zapisujaca do bazy uderza tez do SOAPowych webservices. Tak wiec, moze niech zostanie jak jest do czasu az naprawde nie bede musial tego ruszac. Do tego czasu dowiem sie wiecej o transakcjach.