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.

Zavar az adásban

Azt hiszem a PMD-hez és általában az összes kód-ellenörző szoftverhez hasznos lenne egy extra prioritás paraméter ami egy ruleset-hez megmondja hogy mennyire komolyan kell venni. Például a cyclomatic complexity dolgokat komolyan kéne venni, az pedig hogy egy paraméter nem final pedig lehetne final az is hasznos, de akkora mennyiségben fordul elő, hogy eltakarja az egyébként ennél sokkal komolyabb problémákat.

Jhacks újra elérhető

A JHacks (Java Bütykölő Bázis) visszatért, ismét új domain címen. Régi tartalom, majd ahogy van időm kalapálgatom.
A snipsnap igazán nullfeature wiki, a nagy előrelépés az lenne ha le tudnám váltani, például egy xwiki tetszene.

Mégegyszer köszi Attilának és Kareninnek a segítségért!

A napos oldalon

Nos, rövid lesz mert csak 12:30 körül estem be. Abban a másfél órában amíg ott voltam, semmi marketing nem volt. A sun-os arcok opensource feliratos pólóval (hacker-divat :) népszerűsítették a Sun új stratégiáját. Mindegy, ami szabad, azt szeressem. Nézzük.
Netbeans: Jól beszélt a srác. Az élő demó során persze bugok is előugrottak a rejtekhelyükről, hiszen még csak nem is RC, de kellemes előadást tartott. A GUI editor még mindig veri az eclipse VE-t, viszont a netbeans-nál nekem sokkal jobban tetszett az a kis open source beszéd szintetizáló cucc, amivel a srác demózott, imádnivaló :) A Netbeans Profiler is szép demót kapott persze, bár sok újat nem tudtam meg róla.
OpenESB: Kicsit gyakorlatlanabb előadóval, de amúgy szerintem egy jó áttekintést kaptunk az ESBről és a Netbeans képességeit és láthattuk egy-egy screenshot alkalmával.
És itt el kellett rohannom jegyet beíratni. Nagyon nem jó hogy nem tudok egy szakmai konferencián végig ott lenni, pedig voltam ma 1 órán át olyan meetingen amin fogalmam nem volt hogy mit keresek...
A szünetben összefutottam régi munkatárs arcokkal, persze pont azzal nem tudtam beszélni akivel akartam,

A SUN-nak jár egy köszi, fincsi volt az üdítő, jó volt a hangosítás, én nem láttam marketinget, az előadók pedig jól vágták a témát, már amennyi előadáson ott tudtam lenni :(

A PERMGEN OOM szelídítése

Frank Kieviet ír a blogjában a túlságosan is jól ismert permgen hibáról, és egész érthetően elmondja hogy mi vezet ide. Innentől boldogság lenne, ha lenne valami eszköz ami gyorsan felderíti nekem hogy pontosan mitől történik, hogy nekem már ne kelljen. A karácsonyi kivánságlistámra. Vagy inkáb a születésnapira, de addigra úgyse lesz kész, hacsak nem a jövő évire. Valami build lifecycle-be illeszthető dolog lenne jó.