[Java lista] Válasz: Re: Metodusok cachelese

[istvan.ketler at lhsystems.com]

Hát, szerintem meg elõször legyen meg a kód minél érthetôbben, aztán ha panasz van mérj, majd csak a legvégén optimalizálj, de ne kezdj el használni annotációkat csak azért, mert "különben biztos lassú lenne".

Az is kérdés, hogy egy sokat hívott metódus esetén mekkorára nô a cache és mekkora költséggel lehet kiolvasni. Másrészt tudom-e fejlesztéskor, hogy milyen jellegû adatokkal lesz hívogatva a metódus.

Meg ilyenek.

Udv

Ivan
Sent from my cellular

------ Eredeti üzenet ------
Feladó: sashee [mailto:gsashee at gmail.com]
Elküldve: Tuesday, February 08, 2011 11:39 PM
Címzett: javalist at javagrund.hu <javalist at javagrund.hu>
Tárgy: Re: [Java lista] Metodusok cachelese

Szia,

az annotaciokat mar nem kell parameterezni, ha belep egy @DbQuery-vel
annotalt metodusba, akkor az osszes cache torlodik es elesedik, mivel
ez ugyis csak olvasni fog. Tehat az egesz felvetes 3 db annotaciot
tartalmaz, nem parameterezhetoek, es csak metodusra tehetoek. Cachelo
DAO-t alkalmazok jelenleg, viszont ehhez kellett irni egy csomo kodot
(megha nagyjabol trivialis is volt), ezert is kezdtem el gondolkodni
altalanos megoldason.

Nem tudtam meg eddig, hogy ezt memoizationnek hivjak, ugylatom nehany
nyelvben megvan ennek a tudomanya is. Ahogy latom javaban proxy-val
megoldhato, azonban en inkabb az adatbaziscachelo reszt tartom
fontosabbnak.

sashee

2011/2/8 Zsombor <gzsombor at gmail.com>:
>
>
> 2011/2/8 sashee <gsashee at gmail.com>
>>
>> Sziasztok,
>>
>> ma fejlesztes kozben jutott eszembe egy otlet, es errol kerem a
>> velemenyeteket. Idonkent belefutok, hogy van nehany tisztan
>> funkcionalis metodusom, ami kizarolag az argumentumaibol olvas ki,
>> ebbol csinal valami eredmenyt. Ezt eleg hatekonyan lehet cachelni,
>> minden bemenetre eleg lenne csak 1x kiszamolni. Pl int
>> getMeaningOfLine(Life life){...} eseteben mondjuk lenne rajta egy
>> @Cacheable annotacio, es akkor csak 1x futna le.
>>
>> Viszont ez egy eleg ritka dolog, tapasztalataim szerint sokkal
>> tobbszor fordul elo olyan, hogy adatbazisbol olvasunk ki dolgokat, es
>> azokkal csinalunk valamit, anelkul hogy modositanank barmit is. Erre
>> vannak pl JPA tobbszintu cache, viszont azok legfeljebb a query-ket
>> cachelik, a hozza tartozo java feldolgozast(ami esetenkent eltarthat
>> egy darabig) azt nem. Tehat a legyeg az lenne, hogy a metodusokra,
>> amik adatokat kernek le es dolgoznak fel, lehetne tenni pl egy
>> @DbCacheable annotaciot, ami megintcsak az argumentumok szerint
>> eltarolja, es ha ujra meghivodik, akkor csak azt adja vissza.
>> Ertelemszeruen a db valtozhat, ezert a hivo metodusra is kell tenni
>> mondjuk egy @DbQuery-t, aminek a hatasara torlodnek a cachek, viszont
>> elesednek is, amig a metodusban van a vegrehajtas. Ha egymasban tobb
>> igy felannotalt metodus van, akkor persze a legkulso hatasa
>> ervenyesul. Ertelemszeruen az igy megannotalt metodus nem valtoztatja
>> szamottevoen a db tartalmat.
>>
>> Leginkabb ezt arra tartanam kenyelmes megoldasnak, ha nem igazan lehet
>> szepen megirni a feldolgozast ugy, hogy azonos adatok ne legyenek
>> lekerve tobbszor. Ez altalaban megoldhato lenne mas
>> programstrukturalassal, vagy custom cache osztaly hasznalataval, de ha
>> ez automatizalhato lenne 2 annotacio hasznalataval, akkor az megiscsak
>> kenyelmesebb.
>>
>> Megvalositas szerint akar aspektusokkal akar talan apt-vel megoldhato
>> lenne.
>>
>> Milyen problemak lephetnek fel ezzel kapcsolatban, valamint van
>> ilyesmire mar letezo megoldas?
>>
>> sashee
>
>
> Szerintem nem annyira praktikus annotációkkal programozni, s egy közepesen
> bonyolult helyzetben is már nehéz lesz generikusan fel annotálni a kódot,
> hogy "ha ez a metódus meghívódik X Y és Z paraméterrel, akkor invalidáld A
> és B és C cache-ben ezt és ezt a kulcs tartományt".
>  Ennél sokkal egyszerűbb, ha a "DAO" réteg elé írsz egy cachelő DAO-t ...
> Persze nem hangzik olyan jól, de gyorsabban kész leszel vele, és könnyebben
> át fogod látni mi miért történik :)
>
> Zs
>
>
>
> _______________________________________________
> Javalist mailing list
> Javalist at javagrund.hu
> http://javagrund.hu/mailman/listinfo/javalist
>
>
_______________________________________________
Javalist mailing list
Javalist at javagrund.hu
http://javagrund.hu/mailman/listinfo/javalist

 
Sitz der Gesellschaft / Corporate Headquarters: Lufthansa Systems Hungaria Kft, Budapest, Fövarosi Birosag 01-09-463417
Geschaeftsfuehrung / Management Board: Monika Houck