Cześć wszystkim,
Mam do was doświadczeniu użytkownicy pytanie na które nie mogę znaleźć jednoznacznej odpowiedzi w materiałach na temat Javy. Czy jeśli piszę program np. w JSF to muszą dbać o "bezpieczeństwo" wątków, czy zadba o to kontener? O co mi chodzi konkretnie, obecnie tworzę sobie aplikację w JSF, wszystko za wyjątkiem ziaren JSF traktuję jak zwykłą aplikację desktopową tylko czy to jest prawidłowe podejście? Czy nie powinienem do niech podchodzić jak do pisanie aplikacji wielowątkowej? Kolejny przykład: mam w środowisku jeszcze kilka serwerów WebSphere w wersji 6 z java 5, na szybko musiałem wdrozyc na nich web service, wybór padł na Apache Axis 1.4 i tu znów podszedłem do aplikacji jak do desktopowej, z tym, że na podstawie jednej z klas wygenerowałem web service. To wszystko działa bez zastrzeżeń, do utworzenia tego postu skłoniła mnie tylko jedna sytuacja, a mianowicie pisałem aplikację desktopową wielowątkową w której używałem klasy SimpleDateFormat, która jak się okazało nie jest "bezpieczna" przy wątkach i zgłaszała wyjątek. Podobnego rozwiązania używam w JSF, a przecież tu też w jednym momencie aplikację może wywołać 100 użytkowników w tym samym momencie? Czy wywołanie statycznej metody, która w parametrach przyjmuje obiekt jest bezpieczne w JavieEE (ConvertDate.getString(Date now))? Czy kontener rozwiązuje te problemy? Możecie opisać to po swojemu? Jak wy to robicie? Może jakiś artykuł opracowanie?
Serdecznie pozdrawiam
- JavaEE przed niczym Cię w kwestii wątków nie zabezpiecza
- A nawet trochę pogarsza
- jak sam wystartujesz wątek z JavaEE i zaczniesz coś w nim robić to możesz uzywskać niezłe błędy (transakcje i inne aspekty nie działają w wątkach nie utworzonych przez kontener).
- użycie synchronized i innych takich może spowodowac dramatyczne blokowanie się systemu i nawet nie będziesz mógł wiele z tym zrobić,
- Jednak i tak się synchronized i wątki na małą skalę stosuje. W normalnych warunkach na zdrowy rozsądek da się trochę wątków używać, ale po prostu musisz wiedzieć jak kontener działa (2 lata debugu Websphere lub Jboss i będziesz w tym się w miare orientował, jest spoko). Użyj zdrowego rozsądku i powinno być dobrze... jednak kilka razy ratowałem aplikacje JavaEE bo ktoś gdzieś dał jeden nieszczęsny synchronized (np. na statycznej metodzie),
- Pamiętaj, że SimpleDateFormat to najlepiej nie używać nigdy, podobnie jak java.util.Date - od javy 8 masz java.time pakiet, a przed java 8 ściągasz pakiet jodatime
- Jeśli sam z siebie piszesz program z użyciem JSF to niewiele Ci może pomóc. Jeśli ktoś Ci każe to domagaj się dodatku za szkodliwe warunki pracy.
hasło do wyszukiwarki: "threads in java ee"
wyniki z pierwszej strony:
http://www.adam-bien.com/roller/abien/entry/can_i_start_threads_in
https://www.javacodegeeks.com/2014/07/java-ee-concurrency-api-tutorial.html
Najprościej byłoby pewnie zrobić @Singleton EJB z metodą oznaczoną @lock(WRITE), co będzie skutkować szeregowym wywoływaniem tej metody. Robiąc ManagedExecutorService dałbym mu pulę z tylko jednym wątkiem, czyli znowu szeregowe wywoływanie. Można też użyć jakiejś lepszej biblioteki np JodaTime jak nie masz Javy8. No i generalnie w aplikacjach webowych dobrze jest zwracać uwagę na współbieżny dostęp do beanów o zasięgu aplikacji (tutaj najlepiej właśnie robić singleton ejb), i do bazy danych
Ja w Springu tworze beany niemutowalne w 99% przypadków więc nie martwie sie o wielowątkowość (wszystkie pola finalne, wstrzykiwanie przez konstruktor)
jarekr000000 napisał(a):
- JavaEE przed niczym Cię w kwestii wątków nie zabezpiecza
- A nawet trochę pogarsza
- jak sam wystartujesz wątek z JavaEE i zaczniesz coś w nim robić to możesz uzywskać niezłe błędy (transakcje i inne aspekty nie działają w wątkach nie utworzonych przez kontener).
- użycie synchronized i innych takich może spowodowac dramatyczne blokowanie się systemu i nawet nie będziesz mógł wiele z tym zrobić,
- Jednak i tak się synchronized i wątki na małą skalę stosuje. W normalnych warunkach na zdrowy rozsądek da się trochę wątków używać, ale po prostu musisz wiedzieć jak kontener działa (2 lata debugu Websphere lub Jboss i będziesz w tym się w miare orientował, jest spoko). Użyj zdrowego rozsądku i powinno być dobrze... jednak kilka razy ratowałem aplikacje JavaEE bo ktoś gdzieś dał jeden nieszczęsny synchronized (np. na statycznej metodzie),
- Pamiętaj, że SimpleDateFormat to najlepiej nie używać nigdy, podobnie jak java.util.Date - od javy 8 masz java.time pakiet, a przed java 8 ściągasz pakiet jodatime
- Jeśli sam z siebie piszesz program z użyciem JSF to niewiele Ci może pomóc. Jeśli ktoś Ci każe to domagaj się dodatku za szkodliwe warunki pracy.
Ja nie mam zamiaru stosować wątków w aplikacji JEE, to co mnie zastanawia to właśnie, że mimo ich nie stosowania aplikacja i tak jest wielowątkowa bo chodzi na kontenerze i w jednym momencie o jej zasoby może konkurować 100 użytkowników. Czy w tym przypadku każdy użytkownik to wątek? Jak to ma się do mojego tworzenia aplikacji, w której mam jednego beana jsf który pod spodem woła pojo, i co jeśli mam w wywołaniu statycznej metody objekt? Czy jest możliwość, że niektórzy użytkownicy dostaną identyczną odpowiedz? Może pytanie jest głupie, ale męczy mnie od jakiegoś czasu.
Z SimpleDateFormat rezygnuję:-) Bardzo dziękuję za radę.
Korzystam z JSF + Primefaces, do moich prostych widoków nadają się znakomicie, do bardziej rozbudowanych stron używam Vaadina (szybko i prosto). Dodatkowo JSF jest częścią JavyEE. Co polecasz zamiast JSF+Primafaces?
Każdy jeden request w JavaEE to wątek (zasadniczo).
Twoje pytanie o Beana w JSF:
- Jak masz metodę statyczną to nie problem generalnie (ale potencjalnie dziwne - co robi metoda?) - jeśli masz statyczny (globalny) obiekt no to już masz (problem),
- Normalnie w JSF nie masz problemu o ile nie użyjesz dziwnego Scope (np. Application)
- Twoje pytanie wskazuje, że nie masz pojecia jak to działa - a używasz. TO jest droga do klęski - bo JSF z JavaEE jest dość skomplikowanew działaniu. Chwila nieuwagi i wpadasz na minę (jest ich wiele). Spoko: dwa miesiące z książkami , 3 lata praktyki i będziesz w stanie sobie poraadzić :-).
- Inne frameworki nie są tak skomplikowane i nie mają tyle min. Dlatego polecam rób jak wszyscy - wywal ten JSF. Rób na serwerze w Javie tylko Restowe ednpointy a front zrób sobie np. w angular.io (Single Page Application). Tam jest TypeScript, który nie jest tak zły jak JavaScript. Całość będzie lepiej wyglądać i lepiej działać. (Jak w dowcipie o kalesonach: i cieplej, i czyściej).
A poza tym JavaEE to syf i powinno zginąć. JSF to nie jedyny zepsuty kawałek tej specyfikacji, tylko jedyny, który był zepsuty od początku. Pozostałe były przynajmniej używalne i ciekawe: 10 lat temu....
Zastanawiałem się jak mogę inaczej sforumłować swoje pytanie i takie coś mi przyszło do głowy: jeśli w aplikacji JSF mam singleton to ten singleton jest jeden dla wszystkich żadań/wątków czy jeden dla żądania/wątku? Np. użytkownik loguje się na stonę która pobiera dane z bazy i połączenie tworzy za pomocą singletona to czy ten singleton jest jeden dla żądania czy dla wszystkich żądań?
Czytam, w tym temacie, ale jasnej odpowidzi znaleźć nie mogę, domyślam się, że stawiam sobie źle pytanie.
Singleton jest jeden - jest współdzielony i oczywiście to oznacza, że różne diwne rzeczy mogą się dziać jeśli odpowiednio nie zabezpieczysz go przez wielodostępem. Chyba, że to nie zwykł singleton tylko ejbek annotowany jako @Singleton.
Po treści pytań wnioskuję, że jestes na wielkim polu minowym i nie masz sprzętu ani doświadczenia sapera. O ile Ci za to dobrze nie płacą to najlepiej zostaw to JSF i JavaEE. Raczej Ci nie jest potrzebne, a co najwyżej urwie Ci nogę.
jarekr000000 napisał(a):
Singleton jest jeden - jest współdzielony i oczywiście to oznacza, że różne diwne rzeczy mogą się dziać jeśli odpowiednio nie zabezpieczysz go przez wielodostępem. Chyba, że to nie zwykł singleton tylko ejbek annotowany jako @Singleton.
Po treści pytań wnioskuję, że jestes na wielkim polu minowym i nie masz sprzętu ani doświadczenia sapera. O ile Ci za to dobrze nie płacą to najlepiej zostaw to JSF i JavaEE. Raczej Ci nie jest potrzebne, a co najwyżej urwie Ci nogę.
Nie no zawsze człowiek czegoś się nauczy:-) Ogólnie wszystkie moje aplikacje działają i robia to co powinny. W tym momencie zgłebiam temat i chce jak najlepiej zrozumieć co się dzieje. Książki tłumaczą wszystki czasem zbyt pobieżnie tak jak ja bym już to miał wiedzieć dopiero temat zgłębijąc :-) W IT lepiej jest przepraszać niż żąłować, że się nie spróbowało :-)
Nadal tylko nie rozumiem po co robisz sobie krzywdę tymi technologiami.
Jeszcze JavaEE rozumiem trochę - nadal dużo ludzi wierzy, że ta technologia ma przyszłość.
Dla mnie to szanse mniej wiecej jak na triumfalny powrót Poloneza Caro na salony światowej motoryzacji... - ale wiadomo - są różne opinie.
Pracę w JavaEE nadal się znajdzie i to nawet dobrze płatną (choć w COBOLU jednak nadal lepiej można zarobić).
Ale JSF? (czyli jak to napisał @Koziołek Jeden Straszny Fakup).
Nie, nie nie nie nie nie nie nie nie nie nie rób sobie krzywdy po prostu. Ta wiedza boli.
jarekr000000 napisał(a):
Nadal tylko nie rozumiem po co robisz sobie krzywdę tymi technologiami.
Jeszcze JavaEE rozumiem trochę - nadal dużo ludzi wierzy, że ta technologia ma przyszłość.
Dla mnie to szanse mniej wiecej jak na triumfalny powrót Poloneza Caro na salony światowej motoryzacji... - ale wiadomo - są różne opinie.
Pracę w JavaEE nadal się znajdzie i to nawet dobrze płatną (choć w COBOLU jednak nadal lepiej można zarobić).Ale JSF? (czyli jak to napisał @Koziołek Jeden Straszny Fakup).
Nie, nie nie nie nie nie nie nie nie nie nie rób sobie krzywdy po prostu. Ta wiedza boli.
Mam w pracy narzędzie, które udostępnia Java API, które polega na wywołaniu EJB. Kiedyś musiałem oprogramować kilka ręczych czyności i udostępnić jako web service i tak zaczyła się przygoda z JEE, i jedyne co w niej robie to wołam tego EJB a reszte rozwiazuje za pomoca POJO (stąd próba zrozumienia działania kontenera). JSF mam tylko w jednym jedynym rozwiazaniu i juz wiecej nie zaimplementuje zostane przy Vaadin lub wgyze sie w Angular (ktos tutaj sugerował za co dziękuję). A w COBOLU też zdaży się coś napisać, REXXie czy innych legacy language. Wszystko zależy od problemu i platformy:-)
Jeśli masz to w pracy i dostajesz kasę/ musisz to jesteś rozgrzeszony - co więcej to, że zdobywasz wiedzę i interesujesz się jak to działa to Ci się chwali!
Wiekszość programistów zadowala sie chamskim copy paste ze Stack Overflow i kończy wnikanie jak raz zadziała.
jarekr000000 napisał(a):
Jeśli masz to w pracy i dostajesz kasę/ musisz to jesteś rozgrzeszony - co więcej to, że zdobywasz wiedzę i interesujesz się jak to działa to Ci się chwali!
Wiekszość programistów zadowala sie chamskim copy paste ze Stack Overflow i kończy wnikanie jak raz zadziała.
Bardzo mnie ciekawi i jeszcze mi za to płacą, oczywiście nie zawsze jest czas, ale żeby waśnie go nie marnować to zawsze człowiek coś poczyta np. w stającym w korku autobusie. Jednak wiele opracowań/książek nie odpowie mi tak jak zrobiłeś to ty, za co bardzo dziękuję. Już teraz wiem, że wszystkie Date z paketu javy zomienić na joda, że JSF to strata czasu (który już straciłem) i jestem już powien że wywołanie EJB w moim web service powinno być singletonem, kolejne pytanie co się dzieje jak nie jest :-) Będę szukał i testował dalej.
Hmmm ale przecież gdzieś od wersji 3.1 servletów jest do dyspozycji asynchroniczne IO, co oznacza, że niekoniecznie każde wywołanie HTTP w J2EE to jest osobny wątek. Oczywiście w takim J2EE które implementuje servlety 3.1 w górę i korzysta z AIO
Dzisiaj w ebookpoint jest obniżka cen. Czy ta publikacja Java Beans 3.0 jest jeszcze coś warta na dzień dzisiejszy?
R3id4k napisał(a):
Dzisiaj w ebookpoint jest obniżka cen. Czy ta publikacja Java Beans 3.0 jest jeszcze coś warta na dzień dzisiejszy?
Dla początkującego nie.
Za dużo starych rzeczy, które są już niepotrzebne.
Polecam raczej wykłady i książki Adama Biena - to taki ostatni samuraj JavaEE.
Co do concurrency w JSF wszystko polega na dobraniu odpowiedniego scope do problemu (nieważne czy legacy JSF czy CDI). Ważne jest zrozumienie jak działają scopes w JSF (request, view, session i application/singleton). To jest absolutna podstawa. Inaczej skończy się aplikacją pisaną na @SessionScope.
Dla typowej aplikacji, która używa głównie @ViewScoped: każda zakładka przeglądarki dla tego samego widoku to niezależny stan. Czyli w zasadzie nie ma co synchronizować, bo każda karta przeglądarki ma inny stan bo ma inny UIViewRoot. Dla uproszczenie pominę, że @ViewScoped jest trzymany w sesji: to szczegóły implementacyjne (można poczytać kod Mojarra jak to kogoś interesuje).
Jak używa się np. @Singleon albo @ApplicationScoped to jest to obiekt współdzielony przez całą aplikację, więc trzeba używać synchronizowanych / immutable typów danych, a najlepiej mieć jak najwięcej bezstanowych obiektów. Obiektów @SessionScoped nie używa się aż tak często: ale są współdzielone przez całą sesję i trzeba brać to pod uwagę.
Polecam odpowiedzi od Bauke Scholtz aka BalusC (najlepszy ekspert od JSF, jak kogoś słuchać to na pewno warto poczytać jego):
https://stackoverflow.com/questions/35009907/concurrency-of-applicationscoped-jsf-managed-beans/
https://stackoverflow.com/questions/7410723/are-jsf-2-x-viewscoped-managed-beans-thread-safe
Co do JEE ogólnie, kontener EJB nie był tworzony z myślą o manualnym tworzeniu wątków: zarządzanie pulami wątków to odpowiedzialność serwera aplikacyjnego. W JEE 7 dodali coś takiego jak Managed Executor service, co daje namiastkę transakcyjnych egzekutorów, które można używać z kontenerem.
Również polecam materiały szkoleniowe od Adama Biena. Sporo udostępnia za darmo. Dzięki jego doświadczeniu początkujący mogą wiedzieć, które fragmenty specyfikacji warto pominąć (np. zdalne EJB i dlaczego). I masa dobrych praktyk. Jak wiadomo są to tylko opinie, ale mi mocno uprościły życie jak musiałem pracować z JEE i generalnie uprościły projekt (np. dzięki sugestii Adama pozbyłem się z aplikacji intefejsów, które były obowiązkowe we wcześniejszej wersji tzn EJB 3.0).]
Co do synchronizacji, kiedyś zdarzyło mi się używać @Read/@Write lock na singletonie w EJB 3.1 (do szeregowego wysyłania danych na drukarkę fiskalną). Dwa wątki jednocześnie potrafiły zaburzyć drukowanie paragonu po RS232.
Jak musisz pracować z JSF to warto zobaczyć co pojawiło się w specyfkacji 2.3 (np. serwer push dzięki HTTP/2 i Servlet 4.0, gdy dostępne): .