Asi s krizkem po funuse, ale take jsem neco podobneho nekolikrat resil.
Vzhledem k tomu, ze se v prostredi AS bojim novych threadu a JMS v mnoha
pripadech neni k dispozici (preferuji Tomcat napr. pred JBossem), a tak jiz
delsi dobu pouzivam stale stejny princip zalozeny na servletech (asi neni
originalni, ale me se osvedcil):
1. Klient zasle pozadavek na dlouhe zpracovani -> AS (novy thread / thread z
poolu)
2. Vygeneruje se identifikator pozadavku
3. Zvaliduji se parametry
3.1 Nastal error: Odpoved s chybou klientovi
3.2 Vse OK:
3.2.1. Do Http session se vlozi notifikacni status objekt (na session ma
pristup stary thread vykonavajici business funkcionalitu i thready nove)
3.2.2. Vygeneruje se do response status stranka s odpovedi, ze pozadavek byl
prijat
3.2.3. Zahaji se zpracovani pozadavku ve starem threadu - stary thread zapisuje
stav do notifikacniho status objektu
3.2.4. Status stranka se automaticky refreshuje a pres servlet vypisuje stav z
notifikacniho status objektu (v posledni dobe pouzivam misto refreshe AJAX, coz
je jednodussi a elegantnejsi)
3.2.5. Puvodni thred kona a nastavuje notifikacni status objekt (mozno vyrobit
i bargraf u operaci, kde je mozno prubeh odhadnout). Na konci do notifikacniho
objektu poznamena vysledek
3.2.6. Po ukonceni operace zobrazi status stranka cely vysledek
Vyse zminene reseni ma urcite problemy na serverech s relativne malym poolem
provadecich threadu (WLS), zde je vzdy na zvazeni vyuziti messagingu, ale pozor
na spravne pouziti korelaci zprav tak, aby se vlakna neblokovala. Dale neni
vyse uvedene reseni vhodne pro clustery (dlouhodoby thread neni mozno zmigrovat
a uzivatel prijde o svou praci) - s kvalitnim MOMem toto neni problem.
Jako posledni zminku bych rad upozornil, ze vyvojari casto zapominaji na
synchronizace pri praci s objekty v HttpSession (pri review kodu na to narazim
prekvapive casto).
JM
