WS-Transactions

Második nekifutás WS-Transactions a falnak.
Vagy nagyon advanced dolgot akarok, vagy nagyon nagy hülyeséget, ez remélem hamar kiderül, mindenesetre az élet tranzakciók nélkül piszok nehéz tud lenni, még akkor is ha web servicekről van szó. Persze egyszerű esetekben (örüljön az akinek a munkája egy egyszerű eset) egy tranzakcióban egy WS hívás van, ha sikerül akkor azt lehet mondani hogy oké, ha meg elfekszik akkor rollback és megpróbáljuk később esetleg. Nem ilyen ideális az élete azoknak akik kénytelenek egynél több hívást indítani egy tranzakcióban, főleg ha adat módosításáról van szó.
Kicsit utánnanéztem a WS-AtomicTransaction speckónak, találtam hozzá egy WSDL-t is, szóval akár implementálni is lehetne, csak elöbb gondol, mert annyira azért mégsem sürgős. A saját implementáció azért merül fel lehetőségként, mert még mindig senki sem csinálta meg. Pedig már nem annyira új a dolog, kiváncsi vagyok mi lehet az oka.
Mindenesetre egyelőre egy implementáció lehetőségét keresem, nem túl bonyolult, a kliens oldara kell egy tranzakció interceptor ami a kliens oldalon figyeli hogy létezik-e tranzakció, a hívott WS támogatja-e a tranzakciókat, meghívja a WS-Transactions api megfelelő hívásait, aztán prepare és commit esetén ilyesmi. A szerver oldalon pedig a transaction-managerrel kell összehuzalozni.
Húú, ha csak ilyen igazságosztásból kellene megélnem biztos rohadt könnyű lenne. A gond például a prepare hivásnál van, ahhoz programozói szintről vajon hogy lehet hozzáférni... Sehogy, mi?
Ilyenek lesznek...

Pár link..

• Guy Pardon előadása a Javapolison
• WSDL (Lényeg)
• Speckó, ezt is el lehet olvasni...
  

OpenLaci @ jhacks

Igazából nem lehet panaszkodni az OpenLaszlo dokumentációjára, opensource project létére egész jó :) Persze az is meglátszik a doksi határain hogy a supportból és az oktatásból él a cég. Na ez az, amire egy jó magyar munkásembernek soha nincsen pénze, még ha szoftverfejlesztő is.
Amire igazán kiváncsi lennék az inkáb valós életbeli példák, hogy ki hogyan integrálja spring frameworkkel, hogy használja a data bindinget, hogy ír benne formokat, ilyesmi.
Az első openlaszlo felhasználói találkozón sikerült pár PHP-s sráccal gondolatokat cserélni, bár az nekem kicsit távoli, de semmiképp sem haszontalan. Azóta csend van, mondhatni a magyar OpenLaszlo közösség szép start után elpárolgott.

Úgyhogy elkezdtem a jhacks-on összeírni az OpenLaszlo-ról amit eddig kibányásztam belőle. Majd haladgatok ahogy van időm. Na igen, mostantól kicsit több időm lesz mint eddig. Ha valakinek van kedve nyugodtan szóljon, adok accot és lehet belenyúlni.

Mennyi az annyi...

A JDBC tuningolós bejegyzésben említettem hogy elég impresszív sebességnövekedést lehet elérni olyan dologgal amihez a kliens kódon semmit nem kell változtatni, na itt van egy mérési eredmény.

• AMD 1600-as postgres 8.1 szerver
• AMD 2400-as java kliens, sun jdk 1.6, default VM opciók
  
• persze linux mindkettő
  
• 10/100-as ethernet

Szóval átlagos cucc.
Prepared statement cache nélkül a teszt kód 647 ms
Prepared statement cache használatával a teszt kód 550 ms
A teszt kód egyébként insertekből és deletekből áll, selectekkel valószniűleg nagyobb a különbség mert nem játszik annyit a lassú merevlemez, vm-tuninggal meg méginkáb, mert nem játszik annyit egy rosszul paraméterezett VM. Csak most mindehhez fáradt vagyok.

A kettő között annyi a különbség tehát hogy az első mindig újra létrehozza a PreparedStatement objektumot és újra átküldi a SQL stringet a szervernek, a második eredmény pedig enélkül, csak kis pool logikát használva.

Ez így olyasminek tűnik aminek érdemes utánnanézni holmi tuning esetén, nem?

OSFlash konferencia neten

Akinek van ideje ilyesmire egy deathmatch-pénteken (konkrétan holnap), az ugorjon be bátran egy OSFlash konferenciára, webes persze. Olyan dolgokról beszélnek majd mint flex, red5 és openlaszlo, többek közt.
Lesz róla felvétel is persze, így legalább én is meghallgathatom egy hullaszombaton.

Június Newtech Meetup

Kicsit dotnetes volt, ami nekem ugyanolyan távoli volt mint 2 éve vagy 3 éve, meg teljesen elvetemülten marginális ufótechnológiák. Az előadások mégrövidebbek lettek, és mégkeményebben betarttatták az előadókkal az időkorlátot. Szerintem kicsit túl rövid is lett, mindenesetre annyi biztos hogy ilyen rövid időbe nem fér bele az hogy az előadó bemutatkozzon, azon túl hogy elmondja a nevét persze.
Pazmandi Tamás: Űrhajósok dózisterhelésének meghatározása. Űrtechnológia, a híres magyar fejlesztés, Farkas Bertalan, űrsiklók, arányok és ilyesmi. Tetszett, aki bővebben akar ilyesmiről hallani annak ajánlom az epret.
Kisko Attila: Silverlight Az erő gonosz oldaláról. Még nincs kész a dolog, de valami olyasmiről szól mint nekünk az openlaszlo+red5 meg esetleg flex. Náluk is vannak még problémák, de több pénz és fejlesztő, valószinűleg hamar meglátjuk mi lesz belőle.
Gránicz Ádám: Funkcionális programozás és F# Ádám a vicces nevű funkcionális programozási nyelvről beszélt ugyanazzal a magabiztossággal és lendülettel amivel a nőkről beszélt szinte megállás nélkül amikor még egy csapatban dolgoztunk. Matematikusok a matematikusokért, l'art pour l'art. Ádám egyébként akkoriban eclipse plugint hegesztett OKML-hez, szóval nem lehet azt mondani hogy nem ismeri az erő jó oldalát. Ja, mert ez az egész dotnet.
Marosi István: Karakterfelismerés Ex-Recognitás arc, rövid elméleti összefoglaló a karakterfelismerési technológiákról. Birtam a recognitát, az utódait meg nem igazán.
Németh Ádám: Egységes Instant Messaging hálózat Magyarországon? Jabberről és a köré halmozott dolgokról. Azt hiszem nem is annyira technológiai ismertető volt mint inkáb egy terv és problémás terület ismertetése. A probléma az hogy a szolgáltatók nem akarnak együtműködni, a terv az hogy de mégis kéne, valahogy így, na és a nagy szabvány az a jabber ezen a téren. Jó is a jabber :) Az nekem nem derült ki hogy kinek vagy milyen szervezet a képviseletében beszélt, de szimpatikus ötlet.

Bénázások MINA-val

Kifejezetten szimpi dolog volt a SEDA, és a különböző feldolgozási fázisok bepakolása pipeline-ba, akár IoC-ből is összedobható, mint egy álom :) Szóval első látásra szerelem volt a MINA, a próbahegesztések is jól mentek vele, de aztán furcsa dolgok jöttek elő vele. Egy primitív XML-alapú protokolt akartam összedobni, gondoltam pár perc XStream-mel. Na nem egészen, ugyanis itt szépen szétaprítva kapod az üzeneteket, nem ám holmi stream-ként. Azt meg nem eteted meg egyetlen XML parserrel sem, stream kell és kész. Ehhez találtam a StreamIoHandler-t, ami ugyan nem filter, hanem handler, így csak a pipeline végére passzol, sebaj, na ezzel jöttek aztán a bajok, elnyelt adatok, blokkolt stream, úgyhogy kicsit rákerestem hogy hogy is kéne megfelelően használni, és azt az egy javaslatot találtam hogy leginkáb sehogy :-(
Feltekertem hát Normafára, legurultam, de a problémát ez sem oldotta meg, szívós egy probléma. Esetleg valaki futott már bele ilyesmibe?

Kis JDBC tuning...

Ezt az egészet eddig is tudtam persze csak nem ennyire jól :) Egy éjszakai debug-party alaposan beleverte a fejembe.

Szóval JDBC prepared statementek használatában az a szép, hogy a JDBC Driver -persze paraméterezéstől és implementációtól függően- akár létrehozhatja az adatbázis szerveren a query plan-t, és ezután már csak a paramétereket küldözgeti át. Ez persze csak akkor hatékony, ha sokat használjuk a prepared statementet.
Na és hogy tényleg hatékonyan tudjuk használni, ahhoz például pool-ozhatjuk. Ezt a pool-ozást megvalósíthatja maga a JDBC driver, de a legtöbb alkalmazásszerver is a datasource-okban csinál ilyesmit, azt hiszem a DBCP is például. Ez azért fontos pont, mert nekünk, tudatlan végfelhasználóknak nem kell azzal foglalkoznunk hogy a PreparedStatement-jeink akkor legyenek lezárva ha már tényleg nem akarjuk használni.

A sebességnövekedés egyébként elég impresszív, nem csak a GC-t kíméli hanem az adatbázis szervert is, ami ultrakritikus pontja minden információs rendszernek, valamint a hálózati terhelést is csökkenti kicsit.

A bibliát is jobban tudja
A nőkkel is jobban durva

Járt útat járatlanért

Munkaadómnál, a HumanBrainProgramming Inc-nél a VeryBigCompanyOfAmerica OurOwnVersionControlThatRunsOnlyOnOurSoftware verziókontrol rendszeréről átmigrálunk lassan a CompletelyUnknownCompany VerySpecialProductWithANiceName termékére. A migráció első szárnypróbálgatásai sikeresnek tűnnek, az infrastruktúránkba behelyettesíteni viszont rémálom. A continuous integration rendszerek közül tegnap óta már 4-et kipróbáltam hogy melyik hajlandó vele együttműködni. Eddig egyik se. Az előző megoldást is csak egy continuum SNAPSHOT verzió (pre-alfa) tudta elvinni.

A relációs adatbázisoknál az SQL nyelv azért annyit ért hogy a leggyakrabban használt objektumokat (táblák, tárolt eljárások, triggerek, kütyük és izék) minden termékben ugyanazt a nevet kapták, nagyjából ezek mind ugyanazt csinálják.
A verziókezelőknél ezt a harmóniát még nem sikerült megközelíteni, persze mind kb ugyanazt tudja, de teljesen másként nevezi. Írhatnánk egy SVN-VSS szótárat azoknak akik még nem láttak VSS-t. Bár remélhetőleg már nem is fognak, ha eddig megúszták.
A continuous integration szerverek teljesen a technológiai görbe elején vannak, nemcsak hogy mindent másként hívnak bennük, de a koncepciók is egészen hajmeresztően eltérnek egymástól időnként.

HttpSession használati útmutató

A "felhasználói ülésszak", magyar szakfordításban, ha valaki még nem ismerné.

Szóval arra jöttem rá, hogy cache-nek használni a HttpSessiont közvetlenül, az nem vezet sok jóra. Az actionokban minden tele lesz a cache maintenance logikával, pedig nagyon nem oda való. Viszont könnyen be lehet húzni egy cache implementációt interceptorral a DAO réteg alá, ami backendként használhatja a HttpSession-t is (ha nincs más), így ha az adathozzáférési réteggel nincs semmi gubanc, egyszerűsödhet az adatkezelés tényleges holtprimitív DAO hívásokra. Többnyire. De azért az interceptor logikájával megizzadtam kicsit.

Mostanság erre a nem odavaló dologra jó példákat hoz az élet, például a pornófilmforgatás a munkahelyi ablakom alatt...
Valamint véletlenül átmentem matekból így ebből is kell szóbeliznem. Csupa zavaró dolog.