[Java lista] Metodusok cachelese

[Zsombor]

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

> Szia,
>
> nem, konkretan forditott cacheuritesre gondolok. Tehat nem azt
> mondani, hogy ez a metodus modosit a db-n, es ezert a futasa utan ki
> kell uriteni a cacheket, hanem azt, hogy ez a metodus nem modosit a
> db-n, emiatt minden altala meghivott lekerdezo metodus eredmenyet eleg
> csak egyszer kiszamolni.
>
> sashee
>
>
okĂŠ, de ez a zĂĄrĂłjeles megjegyzĂŠsemet leszĂĄmĂ­tva nem mĂłdosĂ­t semmit a
mondanivalĂłmon:
"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 csak
tapasztalataim szerint ennĂŠl tĂśbbre van szĂźksĂŠg."
S emiatt kĂŠtlem, hogy megĂŠri a belĂŠfeccĂślt energiĂĄt, egy ilyen cache
kifejlesztĂŠse.

Zs




> 2011/2/8 Zsombor <gzsombor at gmail.com>:
> >
> >
> > 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
> >
> >
> > _______________________________________________
> > 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/20110209/c9b922c6/attachment-0001.html