Strategie mapowania dzidziczenia w EJB3.0

W ramach specyfikacji EJB3 możliwe są trzy strategie mapowania dziedziczenia:
1. SINGLE_TABLE - jedna tabela, która zawiera wszystkie pola z wszystkich klas w hierarchii
2. JOINED - tabela na każdą klasę w hierarchii. Tabele dla podklas zawierają jedynie te pola, które są specyficzne dla danej klasy.
3. TABLE_PER_CLASS - tabela na każdą konkretną klasę (nie abstrakcyjną), gdzie każda tabela zawiera wszystkie pola zdefiniowane w super-klasie. Strategia ta jest opcjonalna w specyfikacji EJB3.0.

Cykl życia encji

Stany charakteryzujące instancję encji:
• NEW - instancja encji nie ma identyfikatora perystencji i nie jest skojarzona z kontekstem persystencji
• MANAGED - instancja encji ma identyfikator persystencji i jest skojarzona z bieżącym kontekstem persystencji
• DETACHED - instancja encji ma identyfikator persystencji i nie jest skojarzona z kontekstem persystencji
• REMOVED - instancja encji ma identyfikator persystencji i jest skojarzona z kontekstem persystencji i dodatkowo jest zaplanowana do usunięcia z bazy danych.

Efekty operacji związanych z cyklem życia encji opisano poniżej.
1. Perystencja instancji encji - nowa instancja encji staje się zarządzana (managed) oraz persystentna (peristent) poprzez wywołanie metody persist na niej lub w wyniku kaskadowej operacji persystencji.

Znaczenie operacji persist:
• gdy encja jest w stanie NEW staje się zarządzana (MANAGED). Encja zostanie zapisana w bazie w trakcie komita transakcji lub jako rezultat wykonania flush.
• gdy encja jest w stanie MANAGED jest ignorowana w trakcie operacji.
• gdy encja jest w stanie REMOVED staje się MANAGED.
• gdy encja jest obiektem odłączonym może być wyzwolony wyjątek EntityExistsException w przypadku wywołania operacji lub EntityExistsException lub PersistenceException w trakcie flush lub commit
• dla wszystkich encji (nazwijmy je Y) do których odwołuje się poprzez relacje dana encja, jeżeli relacja do tych encji jest oznaczona jako kaskadowa z cascade=PERSIST lub cascade=ALL operacja jest stosowana do encji skojarzonych (Y).

2. Usunięcie - zarządzana (managed) instancja encji staje się usuniętą (removed) poprzez wywołanie metody remove lub w wyniku wykonania operacji kaskadowej.

Znaczenie operacji remove:
• gdy encja jest w stanie NEW operacja jest ignorowana, ale jest propagowana do encji w relacji
• gdy encja jest w stanie MANAGED operacja powoduje przejście do stanu REMOVED
• gdy encja jest odłączona operacja powoduje wyrzucenie wyjątku IllegalArgumentException
• gdy encja jest w stanie REMOVED operacja jest ignorowana
• faktyczne usunięcie encji z bazy danych następuje po wykonaniu comit lub po wykonaniu flush-a

3. Synchronizacja z bazą danych - stan encji persystentnych jest synchronizowany (synchronized) z bazą danych po zakomitowaniu transakcji. Ta synchronizacja polega na zapisie do bazy danych jakichkolwiek aktualizacji na encji i jej relacjach. Aktualizacja stanu encji zawiera przypisanie nowych wartości do właściwości lub pól persystentnych encji oraz modyfikację zmienialnych wartości dla właściwości i pól persystentnych. Synchonizacja z bazą danych nie zawiera odświeżenia jakichkolwiek zarządzanych encji dopóki operacja odświeżenia nie jest eksplicite wywołana na tych encjach.

Jest ważnym by zapewnić, że zmiany dokonane w części odwrotnej relacji powodowały odpowiednie zmiany w części właściwej, tak by zapewnić by zmiany nie zostały utracone po synchronizacji z bazą danych.


Silnik dostawcy persystencji jest uprawniony do wykonywania synchronizacji z bazą danych w trakcie, gdy transakcja jest aktywna. Można użyć metody flush w celu wymuszenia synchronizacji z bazą danych przez aplikację. Synchronizacja stosuje się do encji skojarzonych z kontekstem persystencji.

4. Encje odłączone (Detached entities) - odłączenie encji może nastąpić w wyniku zakomitowania transakcji gdy używany jest zarządca encji (entity manager) typu transaction-scoped container-managed, zrolbekowania transakcji, wyczyszczenia kontekstu persystencji, zamknięcia zarządcy encji oraz serializacji encji lub przekazania encji przez wartość do separowanej warstwy aplikacji przy użyciu interfejsu zdanego.

Merging Detached Entity State: operacja łączenia (merge) dopuszcza propagację stanu z encji odłączonych do encji persystentnych zarządzanych przez EntityManager-a.

5. Instancje zarządzane - odpowiedzialność aplikacji za zapewnienie, że instancja jest zarządzana w dokładnie jednym kontekście persystencji. Zachowanie nie jest zdefiniowane jeżeli ta sama instancja jest przypisywana do zarządzania w więcej niż pojedynczym kontekście persystencji.

W celu stwierdzenia czy dana instancja encji jest zarządzana w bieżącym kontekście persystencji można użyć metody contains.

contains zwraca true:
• gdy encja została pobrana z bazy danych i nie została usunięta i odłączona,
• gdy instancja encji jest nową i została na rzecz encji wykonana metoda persist
contains zwraca false:
• gdy instancja jest odłączona
• gdy metoda remove została wywołana na rzecz encji lub wystapiło usunięcie kaskadowe
• gdy instancja jest nową i nie została jeszcze wywołana metoda persist na rzecz encji.

Wersjonowanie - adnotacja Version

Adnotacja Version specyfikuje pole lub właściwość typu wersja dla encji i służy jako wartość optymistycznego lokowania. Wersja jest używana w celu zapewnienia integralności w przypadku wykonywania operacji łączenia (merge) i kontroli współbieżności typu optymistycznego.

Reguły dotyczące pól / właściwości typu Version:
1. Jedynie jedna właściwość lub pole dla klasy może być oznaczona adnotacją Version.
2. Właściwość Vesion musi być mapowane do głównej tabeli dla klasy encji.
3. Właściwości typu Version nie powinny być aktualizowane bezpośrednio przez aplikację.
4. Pola następującego typu mogą być oznaczone przez Version: int, Integer, short, Short, long, Long, Timestamp
5. Operacje grupowe (bulk operations) nie respektują atrybutu Version. Tego typu operacje aktualizują poprostu wiersze w bazie danych, niezależnie od wartości wersji. Ponadto, zmiany wprowadzone przez aktualizacje nie są uwzględniane w encjach istniejących w kontekście persystencji.

Domyślne mapowanie dla pól i właściwości nie-relacyjnych

W przypadku pola lub właściwości innej niż właściwość relacyjna nie oznaczonej adnotacją mapującą zdefiniowaną w rozdziale 9 specyfikacji ejb-3_0-fr-spec-persistance (lub w przypadku braku odpowiadającej specyfikacji informacji mapującej w pliku deskryptora XML) stosowane są następujące reguły domyślnego mapowania:
• Jeżeli typ jest klasą, która jest oznaczona adnotacją Embeddable, następuje mapowanie w ten sam sposób jak w przypadku pola lub właściwości oznaczonej jako Embedded
• Jeżeli typ pola lub właściwości jest jednym z podanych, następuje mapowanie w ten sam sposób jak gdyby pole oznaczone było adnotacją Basic: prymitywne typy Java, wrappery na typy prymitywne, java.lang.String, java.math.BigInteger, java.math.BigDecimal, java.util.Date, java.util.Calendar, java.sql.Date, java.sql.Time, java.sql.Timestamp, byte[], Byte[], char[], Character[], enums, lub jakakolwiek klasa oznaczona jako Serializable.

W przypadku, gdy żadna z powyższych reguł nie zachodzi i pole lub właściwość nie zostało oznaczone żadną adnotacją zgłoszony zostanie błąd.

Klasy osadzone (Embeddable Classes)

Encja może używać innych drobnoziarnistych klas do reprezentowania jej stanu. Instancje tych klas, w przeciwieństwie do samych instancji encji nie posiadają identyfikatora persystencji. Zamiast tego, istnieją wyłącznie jako obiekty osadzone
w encji, do której należą. Takie osadzone obiekty należą wyłącznie do encji, w których zostały osadzone i nie są współdzielone z innymi encjami. Próba współdzielenia obiektów osadzonych w ramach encji ma niezdefiniowaną semantykę. Ponieważ takie obiekty nie mają persystentnej identyfikacji, są zwykle mapowane wspólnie z instancją encji, do której należą.

Klasy osadzone muszą być zgodne z wymaganiami dla encji określonymi w pkt 2.1 specyfikacji (ejb-3_0-fr-spec-persistance) z wyjątkiem takim że, klasy osadzone nie są oznaczone adnotacją Entity. Klasy osadzone muszą być oznaczone adnotacją Embeddable lub oznaczone jako takie w deskryptorze XML. Typ dostępu do osadzonego obiektu określa typ dostępu dla encji, w której obiekt jest osadzony. Specyfikacja wymaga obsługi tylko jednego poziomu osadzania.

Adnotacja Embeddable jest używana w celu specyfikacji klasy, której instancje są przechowywane jako nieodłączna część encji i współdzielą identyfikację z tą encją. Każda z perystentnych właściwości lub pól obiektu osadzonego jest mapowana do tabeli bazy danych odpowiadającej encji. Mapowane adnotacje Basic, Column, Lob, Temporal i Enumerated mogą być jedynie przenośnie użyte do mapowania pól lub właściwości persystentnych klasy oznaczonej jako Embeddable.

W celu specyfikacji pola lub właściwości encji, której wartość jest instancją klasy osadzonej należy użyć adnotacji Embedded. Adnotacje AttributeOverride i / lub AttributeOverrides mogą być użyte w celu przykrycia mapowania kolumn zadeklarowanych wewnątrz klasy osadzonej, które są mapowane do tabeli skojarzonej z encją. Nie jest wymagane od implementacji wsparcie dla obiektów osadzonych mapowanych na więcej niż jedną tabelę. Użycie adnotacji Embedded dla pola lub właściwości jest tożsame z użyciem pola lub właściwości klasy oznaczonej jako Embeddable.

Kontekst persystencji dla zarządzanego przez aplikację EntityManager-a

Kontekst persystencji (Persistence context) istnieje od momentu utworzenia Entity Manager-a przy użyciu metody EntityManagerFactory.createEntityManager do czasu zamknięcia Entity Manager-a, czyli do czasu wywołania metody EntityManager.close. Rozszerzony kontekst persystencji pobrany z Entity Manager-a zarządzanego przez aplikację jest niezależnym kontekstem persystencji to znaczy, że nie jest on propagowany wraz z transakcją.

Kontekst persystencji istnieje niezależnie od transakcji, jednakże zazwyczaj w tym samym czasie co transakcja. Entity Manager jest zwykle tworzony zaraz po rozpoczęciu transakcji, a kończy swoje działanie po powrocie z metody (lub w przypadku manager-a zarządzanego przez aplikację) po wywołaniu EntityManager.close.

Co to jest Mapped Superclass ?

Mapped Superclass oznacza klasę, dla której informacja o mapowaniu jest wprowadzana do encji, które z niej dziedziczą. Dla klasy tego typu nie ma zdefiniowanej oddzielnej tabeli. Klasa oznaczona adnotacją MappedSuperclass może zostać zmapowana w ten sam sposób jak encja z wyjątkiem tego, że wprowadzone mapowania będą miały znaczenie jedynie w jej podklasach. Takie zachowanie jest uwarunkowane tym, że dla klasy Mapped Superclass nie istnieje skojarzona tabela. W podklasach, odziedziczone z Mapped Superclass mapowania zostają wprowadzone w kontekście tabel zdefiniowanych dla tych podklas. Odziedziczone informacje o mapowaniu mogą zostać przykryte w takich podklasach przy użyciu adnotacji AttributeOverride i AssociationOverride lub odpowiadających im elementów z XML-a.