Spring, a wielowatkowosc: legalne?

0

Witam,
Jak wiadomo w EJB, kontenerach JEE watkow sie nie odpala. Ma to na celu, aby nie destabilizowac pracy kontenra, na ktorym wspolbieznie dziala wiele watkow, zarzadzanych przez serwer aplikacyjny. Aplikacje enteprise sa bardzo proste i jest to ok (pomijam juz concurrency utitlities w JEE7 i ExecutorService ktory jest przykladem dosc prostej wspolbieznosci, a nie prawdziwej wielowatkowosci).

Czasem jednak chcemy miec mozlwiosc zarzadzania watkami (jak w PTHREADS w jezyku C, czesto z wykorzystaniem wysokopoziomych frameworkow jak java.util.concurrent). Zalezy mi na napisaniu aplikacji, ktora obrabia binarnie tablice danych (obraz i go przetwarza). Kazdy watek zajmuje sie innym fragmentem. Watki musza sie ze soba komunikowac i odpowiednio wyslac dane (potrzebna jest synchronizacja). Mam swiadomosc, ze takie zabawy robi sie raczej w C (ffmpeg i te sprawy). Ale chce porownac wydajnosc i sie czegos nauczyc.

Czy mam mozliwosc wykorzystania Springa (tylko context w celu DI), w aplikacji Javy SE wykorzystujacej java.util.concurrent i operacje na wielu watkach? W JEE jest to zabronione, wiec nie chce kombinowac z CDI. Uruchomienie Springa w srodowisku Javy SE jest banalnie proste. Czy Spring pozwala na programowanie wielowatkowe (poza kontenerem webowym)? Jesli nie, czy istnieje kontener DI pozwalajacy na takie zabawy? Zalezy mi na DI, bo jednak latwiej pisac testy.

Pozdrawiam,

0

Jak najbardziej możesz tak robić.

0

Ok, dzięki. Nie znalazłem nigdzie info, że jest to zakazane w przeciwieństwie do JEE.

0

Nie myl JEE z EJB. EJB to tylko mała część JEE. W EJB sie tego nie zaleca bo beany EJB mogą być na przykład w dynamicznych pulach, w efekcie deklarujesz w aplikacji jednego bezstanowego beana, a serwer aplikacyjny tworzy ich 1000 żeby wyrobić z obsługą żądań.
Spring takich rzeczy generalnie nie robi.

1

Tak, zgadzam się co do EJB. W zasadzie CDI to jest taki Spring i też powinno działać. Ale jak już wchodzimy w szczegóły. Czy aplikacja Spring w kontenerze webowym może korzystać z java.util.concurrent? Mam wątpliwość (bo przecież serwer webowy obsługuje wiele wątków, bo musi jakoś zarządzać wieloma współbieżnymi połączeniami). Java SE bez webowych class loaderow jest prostsza, więc spodziewam się mniej problemów.

Jak już został poruszony offtop co do tworzenia 1000 beanów (pule obiektów). Czy jest jakoś udowodnione, że taki bezstanowi bean EJB (pula obiektów) jest szybszy od analogicznego tworu tzn. bezstanowego singletona w Springu? Bo dla małych aplikacji nie robi.

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