ejb - @asynchronous vs thread

Hej,

W przypadku, gdy metoda biznesowa tego wymaga, lepiej jest stosować własnoręcznie oprogramowane wątki (np. fork/joina) czy może lepiej korzystać z adnotacji @Asynchronous ?

Ej. @niezdecydowany ? :P
Po przeczytaniu mojego pytania czy wtf ten paraliż mózgu? :)

Generalnie w 99% przypadków lepiej używać mechanizmów wbudowanych. Własne pisze sie tylko jeśli jest ku temu konkretny powód. Na przykład potrzebujesz jakąś szczególną logikę zastosować, albo robisz cuda na kiju z rozproszeniem i standardowe mechanizmy się nie nadają itd.

@Shalom - fork join jest czescia javy, tak samo jak adnotacje :)

Jasne i ręczne locki w java.util.concurrent też są, a mimo to lepiej jednak korzystać z synchronizacji ;] I zgodnie z twoją logiką to przecież mógłbym też sam zaimplementować sobie kolekcje, jakąś listę czy mapę, bo wszystkie potrzebne elementy "są częścią javy", czyż nie?
Chodzi o to ze jeśli kontener ma już wbudowane zarządzanie pulą wątków do wykonywania zadań asynchronicznych to nie ma sensu pisać tego samodzielnie. Szczególnie że zwykle koderzy którzy pisali serwer aplikacyjny / framework są znacznie lepsi niż "przeciętny koder" i ich rozwiązania są lepsze.

Pójdziesz do pierwszej pracy to ci wybiją z głowy takie pomysły. Jasne, jeśli jest taka potrzeba bo coś się nie skaluje to można sie bawić w optymalizacje przez ręcznie stosowanie locków (chociaż po prawdzie to należy stosować obiekty immutable, stateless i podejście funkcyjne i wtedy w ogóle nie trzeba sie bawić w synchronizacje). Ale przedwczesna optymalizacja nigdy nie jest dobra. Poza tym jeśli ktoś stosuje ręcznie locki albo np. wait i notify to w 99% przypadków będzie to źródłem błędów, deadlocków, race conditions i innych trudnych do wyśledzenia problemów.
To że coś jest "szybsze" wcale nie znaczy że jest "lepsze". W rzeczywistości zwykle liczy się:

• szybkość pisania kodu
• łatwość utrzymania kodu
• czytelność kodu
  Wprowadzanie do kodu niskopoziomowych mechanizmów, albo ręcznej zabawy wątkami sprawia że kod pisze się dłużej, jest znacznie mniej czytelny i jako że kodu jest więcej i jest bardziej skomplikowany to jest trudniejszy w utrzymaniu. A korzyści zwykle są pomijalne bo zyskujesz milisekundy na lockowaniu podczas gdy logika biznesowa, komunikacja ze zdalną bazą danych, komunikacja z webserwisami i tym podobne mechanizmy kosztują cię tysiące razy więcej i to one są operacjami "wiodącymi".

Wyjaśnij różnice w skalowalności synchronized i te z java.util.
Próbujesz znowu mi "pojechać", że jestem noobem z gimnazjum.

Absolutnie nie! Po prostu wygłaszasz opinię która wskazuje na to że nie masz jeszcze zbyt dużo komercyjnego doświadczenia, nic więcej. Wcale nie kwestionuje twojej znajomości technologii, a jedynie brak znajomości realiów pracy programisty.
O różnicy w skalowalności przecież już wiesz, bo sam pokazałeś link który o tym traktuje -> pokazuje że ręcznie zarządzanie lockami skaluje się czasem lepiej. Przypadek ekstremalny stanowiłaby sytuacja kiedy masz 2 rodzaje wątków które mogą korzystać z pewnego zasobu wspólnie w ramach typu. W efekcie w sekcji krytycznej możesz mieć wiele wątków X albo wiele wątków Y. Zrobienie tego w naiwny za pomocą synchronized spowoduje wąskie gardło bo w sekcji krytycznej będzie zawsze tylko 1 wątek.