Czy przy połączeniu klienta (Remote) z z serverem do danego EJB na serverze przez pobranie (w kodzie klienta) InitialContext a potem referencji do tego obiektu EJB z InitialContext następuje rzeczywiste pobranie obiektu (czyli stworzenie duplikatu u klienta) czy tylko referencji do niego (a obiekt jest tylko na serverze)?
A co za tym idzie: czy wywołana potem u klienta metoda interfejsowa na tym pobranym session bean jest realizowana na maszynie wirtualnej klienta czy servera?
Czy to ze klient jest Local a nie Remote coś zmienia w przypadku powyższego pytania?
0
0
Oczywiście że wszystko wykonuje się na serwerze! Przecież o to właśnie chodzi. Klient dostaje tylko obiekt "proxy". Działa to podobnie jak RMI.
Jeśli używasz interfejsu Local a nie Remote to jest inaczej. Ale używać Local mozesz TYLKO jeśli twoje EJB i klient są uruchomione na tym samym JVM, w efekcie można wtedy pominąć cała warstwę wywołań zdalnych i po prostu odwoływać się do obiektu bezpośrednio. Zasadniczo nadal wszystko wykonuje się na serwerze, ale wtedy serwer i klient są na tym samym jvm.
0
Dzięki. Ale to wywołuje kolejne pytanie.
EJB na serverze ma przypisywany (tworzony) adres JNDI w momencie startowania servera. Czytałem że EJB (jako obiekt swojej klasy) jest zazwyczaj tworzone na żądanie klienta. Czyli ten adres tworzony na starcie jest tylko zarezerwowanym slotem pod EJB które powstanie gdy zgłosi się klient? Czy też EJB tworzone jest wraz ze startem servera i udostępnianie na życzenie?
No i najważniejsze: jeżeli jest ono (obiekt EJB) cały czas na serwerze to czy kilku klientów remote zalogowanych do tego servera na raz, żądających dostępu do tego samego EJB (czyli zasobu JNDI) działa na jednym obiekcie czy też każdy z nich otrzymuje swoją własną kopie tego obiektu na serverze do zdalnego działania na nim?
Jeżeli ma ktoś dobrego (wyczerpującego) linka do tematów EJB i Servlet to proszę o podanie bo ja mam tylko jakieś szczątkowe prezentacje. Nie mogę znaleźć objaśnionych przykładów wiązania EJB z obiektami danych JPA.
Z góry dziękuję.
0
Wpisz sobie system outy w metodach tworzących albo przeczytaj coś na temat ejb? ;]
Obiekty są tworzone dopiero na żądanie, ale później to już zależy. Stateless są usuwane automatycznie przez kontener, stateful nie, ale nieużywane mogą zostać deaktywowane przez kontener.
Jeśli chodzi o to kto korzysta z jakiego obiektu to nie takie proste. Jeśli masz beany stateless to wywołując na beanie 2 metody nie masz nawet pewności że wykonają się one na tym samym beanie (w przypadku stateful masz taką pewność).
Z tym brakiem materiałów to chyba sobie robisz jaja. Zbanowali ci google i stronę suna/oracla? o_O
http://download.oracle.com/otndocs/jcp/ejb-3_0-fr-eval-oth-JSpec/
tu masz specyfikację w której w zasadzie wszystko masz opisane (zakładam ze mówisz o EJB 3, skoro piszesz o JPA)
http://jaiswaltraining.com/servlet/index.php
tu masz dość fajne tutoriale pokazujące proste przykłady dla EJB, JPA, Servletów etc przy czym są one dość stare w związku z czym olałbym instrukcje instalacji serwera aplikacyjnego na przykład i skupił się tylko na elementach mówiących o implementacji (bo mam nadzieję że umiesz zainstalować sobie serwer i umiesz deployowac na nim beany / servlety)
0
Dzięki za odpowiedź. Linka do tej dokumentacji EJB w Oracle to miałem ale ciężko mi tam znaleźć konkretne szczegóły, czyli odpowiedzi na pytanie które mi się rodzą.
Dopytam więc tylko dla pewności. Jeżeli mam bean stateless to każdy klient próbujący korzystać z takiego beana w tym samym czasie ma swoja osobna instancje tego beana? Nie trzeba się martwić o synchronizację rozbudowanych metod interfejsowych tego beana gdyby np. w trakcie ich wykonywania, dla pierwszego klienta, jakieś wyniki pośrednie lądowały w jakichś polach obiektowych a w tym czasie drugi klient chciałby wywołać ten sam bean i jego metodę (to samo JNDI )? Czyli dwa osobne wątki i dwa osobne obiekty pod tym samym adresem JNDI w tym samy czasie?
0
Jejku na prawdę nie możesz sobie tego doczytać? Warto!
W przypadku beanów stateless nie jest tak że każdy dostaje "swojego beana". Jest tak że w kontenerze masz N beanów i one są przydzielane M użytkownikom wg potrzeb na czas wykonywania pojedynczej metody (kontener tworzy nowe w razie potrzeby, ale zwykle trzyma mniej beanów niż użytkowników). Jak już pisałem wyżej - nie masz pewności że wywołując dwie metody wywołasz je na tym samym beanie! Nie musisz się martwić o żadną synchronizację ALE nie wolno ci zapisywać żadnych danych pośrednich w polach takiego obiektu!
stateless—the session bean instances contain no conversational state between methods; any instance can be used for any client.
Stateless session beans are session beans whose instances have no conversational state. This means that all bean instances are equivalent when they are not involved in servicing a client-invoked method.Because all instances of a stateless session bean are equivalent, the container can choose to delegate a
client-invoked method to any available instance. This means, for example, that the container may delegate
the requests from the same client within the same transaction to different instances, and that the
container may interleave requests from multiple transactions to the same instance.
A container only needs to retain the number of instances required to service the current client load. Due
to client “think time,” this number is typically much smaller than the number of active clients. Passivation
is not needed or used for stateless sessions. The container creates another stateless session bean
instance if one is needed to handle an increase in client work load. If a stateless session bean is not
needed to handle the current client work load, the container can destroy it.
Traktuj stateless beany jak webservice. Skoro są stateless to znaczy ze NIE przechowują żadnych danych związanych z tożsamością obiektu. Jesli chcesz pomiędzy metodami przchowywać jakieś dodatkowe dane to musisz użyć beanów stateful!
0
Dzięki za to wyjaśnienie. Przelecę ta dokumentację bo parę zagadnień w tych beanach wydaje mi się wzajemnie nie spójne. Gdzieś muszę coś źle interpretować.
Jeszcze raz dzięki.
0
Przeszedłem przez tą dokumentację EJB (w wersji simplified) i mam jeszcze pewne niejasności. Może to przeoczyłem czytając całość. Dlatego jeszcze jedno pytanie. EJB stateless nie przechowują żadnych danych, z tego jak rozumiem, są tylko elementami (triggerami) do wyzwalania zaimplementowanych metod interfejsowych wpisanych w klasach tych EJB. Mają umożliwiać tylko dostęp z poziomu klienta do danych metod. Może co najwyżej, dostarczają jakieś stałe dane do opera z np. swoich (klasowych) pól statycznych.__ Po co wiec jest ich tworzonych, kilka danego rodzaju, w kontenerze na serwerze? __ Nawet jeżeli jest ich mniej niż klientów to i tak wystarczyłby tylko jeden dla wszystkich połączeń (realizowanych równolegle) gdyż obiekt ten wskazuje tylko kompilatorowi i wirtualnej maszynie, że dany klient chce użyć danej metody. Może więc w ten sposób obsługiwać wszystkich klientów (jako wskaźnik).
0
Odpowiedź jest dość trywialna: ze względu na synchronizację, albo raczej jej brak ;] Te obiekty nie mają wymuszonej żadnej synchronizacji więc nie można założyć że są thread-safe.
Sytuacja mogła by być taka:
Twój bean realizując metodę X() zapisuje sobie w jakichś prywatnych polach obiektu jakieśtam tymczasowe dane (np. dlatego że wywołuje sobie metodę Y() i nie chciał przekazywać tam miliona parametrów)
Co się stanie jeśli mamy jednego Beana i dwa obiekty spróbują wywołać X() z różnymi parametrami? Otóż nie wiadomo, bo może się okazać że wywołanie pierwszego X() zostanie przerwane i zacznie się wykonywać drugi X() który podmieniłby te parametry.
Gdyby bean był jeden to mogłoby się okazać że jest wąskim gardłem - jego operacje musiałyby być synchronizowane i realizowane sekwencyjnie dla kolejnych klientów. A jeśli bean robiłby coś co trwa długo (np. komunikował się w jakimiś innymi zdalnymi obiektami) to by była tragedia. Poza tym zakładamy że obiekty EJB nie są jakimiś zasobożernymi potworami i można stworzyć N instancji.
0
No ale, jak ustaliliśmy, w EJB stateless nie ma zapamiętywania danych pośrednich w polach obiektowych. Obiekt proxy (odwzorowani EJB) po stronie klienta otrzymuje (jak rozumiem) tylko finalny wynik. Gdzie więc mogą pojawić się zapisane wyniki pośrednie? Zmienne metod tworzone w metodzie dostępne są tylko dla danego wątku i każdy wątek ma ich swoja własną kopie (wersję) więc przeplot wątków w trakcie realizacji tej samej metody nie powinien być dla nich groźny.
0
Nie nie nie. Nie wolno zapamiętywać danych POMIĘDZY wywołaniami metod EJB, ale przecież nasze EJB może mieć też kupę metod prywatnych, na zasadzie:
metoda dostępna przez interfejs Remote - X(), która wywołuje sobie trzy prywatne metody (które nie są dostępne dla użytkownika).
Zresztą tak jak mówiłem - jeden obiekt EJB mógłby spowodować gigantyczny spadek wydajności, bo przecież wykonania byłoby sekwencyjne ;]
0
Przy wielowątkowym procesorze dwa wątki realizacji (wywołania) tej samej metody na tym samym obiekcie (przy założeniu niezapisywania przez EJB danych pośrednich w polach prywatnych) nie polecą równolegle? Muszą się sekwencjonować?
0
Jeśli ten obiekt jedyne co wykonuje to jakieś lokalne obliczenia, to pewnie się zrównolegli. Ale bierz pod uwagę fakt że on się może jednak komunikować z kimś innym. Na przykład z jakimś EntityManagerem, który nie jest thread-safe. Zresztą robi się z tego strasznie akademicka dyskusja ;]
0
Pierce111 napisał(a)
Przy wielowątkowym procesorze dwa wątki realizacji (wywołania) tej samej metody na tym samym obiekcie (przy założeniu niezapisywania przez EJB danych pośrednich w polach prywatnych) nie polecą równolegle? Muszą się sekwencjonować?
Normalnie moga leciec rownolegle, ale EJB to specjalny przypadek - tutaj kontener zapewnia ze ta sama instancja nie bedzie wywolywana rownolegle.
No chyba, ze mowimy o singleton bean zdefiniowanym tak ze sam zarzada watkami... Ale to inna bajka.
EJB wcale nie musza byc tworzone lazy i pozniej od razu wywalane po uzyciu - moga byc tworzone na starcie cale poole, np setki sztuk, i zyc sobie spokojnie az nie wylaczysz serwera. Albo moga faktycznie byc tworzone za kazdym razem gdy trzeba. Wszystko to jest dozwolone i tzw. implementation specific, a specyfikacja pozwala na takie dowolnosci.
Shalom napisał(a)
Jeśli ten obiekt jedyne co wykonuje to jakieś lokalne obliczenia, to pewnie się zrównolegli. Ale bierz pod uwagę fakt że on się może jednak komunikować z kimś innym. Na przykład z jakimś EntityManagerem, który nie jest thread-safe. Zresztą robi się z tego strasznie akademicka dyskusja ;]
Rozne instancje EJB nie beda mialy dostepu do tej samej instancji EntityManagera, o to dba kontener. Chyba ze mowimy o Stateful Beanie ktory wola kolejny stateful, wtedy nastepuje propagacja kontekstu transakcji i em, ale wtedy nie zachodzi zadne zrownoleglenie.
0
Dzięki