[Java lista] Metodusok cachelese

[Zsombor]

2011/2/8 sashee <gsashee at gmail.com>

> 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
>
>
Szia !

 Persze, az adott esetben elhiszem, hogy ilyen egyszerĹą cache megoldĂĄs
megteszi - azaz egy mĂłdosĂ­tĂł metĂłdus utĂĄn az Ăśsszes cachet ĂźrĂ­ted (mondjuk
akkor ĂŠn nem a DbQuery hanem mondjuk DbUpdate vagy DbUpdater annotĂĄciĂłt
hasznĂĄlnĂŠk :) ), csak tapasztalataim szerint ennĂŠl tĂśbbre van szĂźksĂŠg.

Zs



> 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
>
--------- következő rész ---------
Egy csatolt HTML ĂĄllomĂĄny ĂĄt lett konvertĂĄlva...
URL: http://javagrund.hu/pipermail/javalist/attachments/20110208/4c2cbfd9/attachment-0001.html