[Java lista] j2ee hatterben futo szal

[bognár attila]

>>> hol van ilyen ellenjavallat a szabványban servlet container esetén?
>>>       
>> jogos, gyorsan atneztem a 2.4-est de nem latom benne. lehet 
>> regebben volt, lehet rosszul emlekszem (tehat nem as far as i 
>> recall :))
>>     
>
> Tegnap belefutottam egy blog bejegyzesbe, amiben ugyanezt a kerdest
> feszegetik. A commentek kozt van nehany erdekes megjegyzes felvetes
> arrol, hogy milyen mellekhatasai lehetnek a servletbol torteno szal
> inditasnak: http://blog.w1c.ca/?p=92
>   

köszi a linket. amit leszűrök belőle és úgy általában:

- mindenki szeret általánosságban úgy beszélni az EE-ben megvalósított 
alkalmazásokról, mint amiket feltétlenül kell tudni a végtelenig 
skálázni, "hibatűrni" (olyan szempontból van alapja, hogy E mint 
Enterprise, olyan szempontból szerintem rossz a megközelítés, hogy közel 
sem minden EE alkalmazás ilyen)

- természetesen - mint mindenhol máshol, legyen az egy egyszerű vonalkód 
generáló - meg kell nézni, hogy minek milyen hatása van/lehet az egész 
rendszerre, alkalmazását vagy annak módját ettől kell függővé tenni. 
Szerintem ebben (remélem) semmi új nincsen, csak az emberek szeretnek 
mindent egy kalap alá venni, azaz vagy fehér, vagy fekete, szürke nem 
nagyon van, a zöldet már nem is említve.

- az első megjegyzés az említett oldalon: eleve rossz, mert miért kell 
azt feltételezni, hogy minden kéréshez generálunk egy vagy több szálat? 
jó, hogy a példa esetleg sugall ilyet, de nem a konkrét példa volt a 
lényeg, hanem egy lehetőség, hogy miért akarhatunk saját szálat indítani.

- folyamatosan a háttérben futó szál mindenképpen foglal erőforrásokat, 
függetlenül attól, hogy miként indul: ha minden kéréshez 3 raklap 
feladatot kell elvégezni a háttérben, akkor az 3 raklapnyi feladat 
erőforrást fog igényelni. Lehet ütemezni stb? Természetesen, de ilyet is 
lehet akár saját kezűleg is. (mellesleg elég béna megoldásnak tartom, 
mikor egy crontab hivogat egy wget-et, nekem erről leginkább a 
kalapácsos autószerelés jut eszembe)

- szál állapota hibatűrés esetén: szerintem az már tervezési és 
megvalósítási kérdés, hogy egy szál "csak úgy" van, vagy pedig az 
állapotát vagy azzal összefüggően bármi mást eltárolunk valahol annak 
érdekében, hogy nyomon tudjuk követni a rendszerben zajló folyamatokat. 
Itt is nyilván mérlegelni kell, hogy milyen környezetben dolgozunk, mit 
kell megvalósítani stb

- biztos nagyon jó minden hiper szuper EE komponens + feature + stb, de 
a nagy problémám nekem az, hogy tegnap is azt hallottam egy 
rendszermérnöktől, hogy valaminek azért kell 4 GB memória, mert az 
alkalmazást Javában írták. Lehet erre nagyon sok mindent mondani, 
hosszan fejtegetni, de egy dolgot nem lehet kétségbe vonni: 4 GB memória 
kell valami olyannak, ami valószínűleg sokkal kevesebbel is működhetne.

- minden felett persze lehetnek különféle szabályzatok, pl fejlesztési 
irányelvek, amik tiltják a saját szálak használatát. Ez nyilván (ismét) 
nagy mértékben függhet a gárdától, a megoldandó feladattól, határidőtől, 
költségkerettől stb. A gond ott van, hogy ez terjed el, és sokan 
(legtöbben, szinte mindenki) is azt hiszik, hogy nem lehet saját szálat 
indítani, mert a specifikáció tiltja, ergo bekötött szemmel járkálnak, 
adott esetben fejlesztik a mamutabbnál mamutabb alkalmazást egy hello 
world kiírására. Amivel az a legnagyobb gondom, hogy a Java még mindig 
úgy "tündököl", mint egy erőforrást zabáló platform.


üdv,

attila






--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: http://javagrund.hu/pipermail/javalist/attachments/20061201/f3d6cbd6/attachment.html