EJB 3.0

0

Witam
Mam pytanie do osob,ktore mialy stycznosc z EJB 3.
Pracuje nad projektem zwiazanym z dostepem do baz danych korzystajacym z tej technologi.
Chodzi mi o sposoby realizacji zapytan do bazy danych,z tego co wyczytalem nie ma juz podzialu,jak bylo w EJB 2.1 na CMP i BMP,usunieto interfejs HOME.
Pozostalo Local i Remote interface.
Jaki jest najlepszy sposob realizacji tych zapytan??
Klient ma wykorzystywac obydwa interfejsy,ale ne wiem jak to bedzie w kwesi zarzadzania trwaloscia.
Nie ma juz BMP ale jest mozliwosc w ziarnie sesyjnym samodzielnego tworzenia EntityMenagera i przejecia,przynajmniej czesci zadan, ktore wykonuje kontener,ale nie wiem za bardzo czy roznice w dostepie do bazy beda tak rozne(o ile w ogole jakies beda) jak w EJB 2.1 dla BMP i CMP.
Generalnie naistotniejsze jest dla mnie ile jest sposobow dostepu do bazy przez ziarna w tej technologi.

0

Jest jeden słuszny sposób czyli @EntityManager. Można sobie niby pisać coś w JDBC, ale po co jak masz JPA? Jedyny problem to konieczność wysyłania obiektów z interfejsu zdalnego na serwer. Może się okazać, że masz już nieaktualne dane.

0
Koziołek napisał(a)

Jest jeden słuszny sposób czyli @EntityManager.

EntityManager nie jest adnotacja, jak moglaby wskazywac ta wypowiedz, tylko zwyczajnym intrfejsem. Wstrzykuje sie za pomoca @PersistenceContext.

Koziolek napisał(a)

Jedyny problem to konieczność wysyłania obiektów z interfejsu zdalnego na serwer. Może się okazać, że masz już nieaktualne dane.

Na pewno jedyny? Ten akurat mozna prosto rozwiazac za pomoca wersjonowania (@Version).

0

Hej dzieki za szybka odpowiedz.
Zapoznalem sie juz z interfejsem EntityMenagera, rozumiem ze to najbardziej oczywiste rozwiazanie i nawygodniejsze zarazem, ale mnie interesuja jakies inne metody.
Kontener jest na tej samej maszynie co klient,mam za zadanie porownac szybkosc dostepu do bazy przy wykorzystaniu roznych metod dostepu wykorzystujacych EJB, jak np porownanie interfejsu remote(na tej samej maszynie zeby wykluczyc narzuty czasowe sieci) i local, zapytan w Native SQL i EJB QL.
Jesli macie jakies uwagi to chetnie wyslucham,bo poki co zapoznaje sie z teoria,a jak sami wiecie,teoria a praktyka to dwie rozne rzeczy...;)
np zaciekawiła mnie ta uwaga odnosnie problemow z remote:

pikseloza napisał(a)

Na pewno jedyny?....

Mozesz napisac cos wiecej?co masz przez to na mysli??

0

Czasami trzeba sie naglowic w konfiguracji asocjacji (eager / lazy). Dla kogos kto nie ma wiele doswiadczenia z baza danych ale costam lyknal, oraz nie ma doswiadczenia w programowaniu, mapowanie relacyjno-obiektowe moze poczatkowo sprawic problemy z ogarnieciem - np. ja mialem trudnosci. Co wiecej, na pewno kazdy uzywajacy mapowania sie z tym spotkal przynajmniej raz - slynny LazyInitializationException (to akurat blad Hibernatowy, ale majacy swoj udzial w innych implementacjach JPA), gdy mamy obiekt w stanie odlaczonym (detached) a probujemy wyciagnac z niego pola / kolekcje leniwe (patrz pierwsze zdanie tego posta). Jesli pisze sie aplikacje od zera, to wszystko spoko, narzedzia danego providera JPA moga nawet dla nas wygenerowac schemat, jednakze przy koniecznosci napisania nowej wersji aplikacji do starego (tzw legacy) schematu, czasami trzeba sie niezle nagimnastykowac aby wszelkie cuda i pomysly sprzed 10 lat rozsadnie zamodelowac.
Co do interfejsow local vs remote, to EntityManager nie ma z tym nic wspolnego - one dotycza beanow sesyjnych, ktoych logika moze wykorzystywac JPA (EntityManager). Zatem, twoje testy by sie ograniczyly do tego ze bys sprawdzal jak bardzo rozni sie czas wywolanie metod beanow lokalnych i zdalnych, bo wewnatrz nich entity managery juz beda mialy taki sam tryb dzialania (no chyba ze rozne managery beda uzywac roznych baz na roznych serwerach).

0

Wlasnie o to mi chodzilo, dzieki za pomoc:)

1 użytkowników online, w tym zalogowanych: 0, gości: 1