2011-11-14 4 views
8

Mam debugowanie naszej aplikacji internetowej. Jest skonfigurowany do tworzenia komponentu bean DataSourceTransactionManager, a także komponentu bean HibernateTransactionManager podczas uruchamiania. Nie jest to zamierzone działanie, ale spowodowane jest uzależnieniem od strony trzeciej. Efekt wydaje się łagodny. To, co widzę poprzez debugowanie, polega na tym, że gdy utrzymujemy obiekt za pośrednictwem DAO opartego na Hibernacji - wywoływany jest DataSourceTransactionManager, a nie HibernateTransactionManager (oba komponenty są nazywane "transactionManager"). Wiosenna Javadoc implikuje (myślę, że ją teraz ponownie odczytam) jest to dobre dla lokalnych zasobów - taka jest nasza sytuacja. To znaczy. nie jest rozproszonym środowiskiem opartym na JTA.Czy można używać DataSourceTransactionManager do utrzymywania ORM zamiast HibernateTransactionManager?

Moje pytanie brzmi - czy istnieje jakikolwiek negatywny wpływ niewykorzystywania HibernateTransactionManager dla trwałości opartej na ORM. Mogę zmienić konfigurację, aby użyć HibernateTransactionManager poprzez kwalifikator na adnotacji @Transactional na naszych DAO.

Wszystko działa dobrze w prosty test jednostkowy, konfiguracja testu integracji, ale jestem bardziej zaniepokojony skalowaniem do pełnej wielkości produkcji, gdy będziemy mieć tysiące użytkowników i wysoki poziom współbieżności.

TIA, mam nadzieję, że to nie jest zbyt mało znane.

Sprężyna 3.0.x BTW.

To jest na wiosnę 3.1.

Sec 11,9 "Rozwiązania typowych problemów".

Użyj prawidłowej implementacji PlatformTransactionManager opartej na do wyboru technologii transakcyjnych i wymagań.

Odpowiedz

6

To uderzyłoby mnie jako niewłaściwe i spowoduje problemy. Bez menedżera txn hibernacji wszystkie wywołania wykonane w HibernateOperations będą poza transakcją i w oddzielnej sesji, w miarę możliwości za pomocą funkcji automatycznego zatwierdzania. Może się więc wydawać, że wszystko jest w porządku, gdy wystąpi błąd, może się okazać, że zmiany, których oczekuje się, że zostaną wycofane, nie są.

Spróbuj wykonać następujące czynności, aby sprawdzić

  • rozpocząć tran
  • zapisać coś
  • rzucać wyjątek
  • popełnić

Sprawdzić, czy 'coś' pojawia się w DB, czy nie.

Kolejna kontrola byłaby

  • rozpocząć tran coś
  • obciążenia
  • dostępu relacją do innego obiektu z czymś i dostęp do nieruchomości (PK) od powiązanego obiektu

Może się okazać, że ostatnie wywołanie powoduje wyjątek, ponieważ sesja nie była otwarta od obciążenia, ponieważ otaczający txn nie jest zarządzany przez menedżera txn hibernacji.

+0

+1 Hmm. ciekawy. Dziękuję Ci. spróbuje jednego z tych testów. Widzę, że połączenia DAO odbywają się w ramach transakcji, a połączenia DAO getSession() - więc Spring SessionFactoryUtils oddaje nową sesję i wszystko wydaje się w porządku. ale jak mówisz - jak często pamiętamy, żeby odpocząć w wycofywaniu. –

+4

Niezły. Próbowałem tego testu. Spowodował wyjątek po zapisie, z funkcją mber hibernacji tgr został wycofany. Z DataSourceTransactionManager tak nie było. –

+0

Czy możesz podać oficjalny dokument potwierdzający twoje słowo "Bez menedżera txn hibernacji wszystkie połączenia wykonane do HibernateOperations będą poza transakcją i oddzielną sesją"? Używam DataSourceTransactionManager + Hibernate. – DerekY