Ahoj, díky, 2nd level cache se mi nechce použít přesně z těch důvodů, že při nové session jsou potřeba čerstvá data. Asi by to šlo řešit přes cache region a nějaký event listener na konec a clear session, který by čistil pouze tuto cache region.
Aspect je zajímavé řešení, jen by se též data v cache musela nějak čistit, i když by se aspect nevolal. Ano přepsat aplikaci také lze. Jen mi tak připadá, když Hibernate session kešuje podle ID, tak je trochu nesystémové, že neumí i query cache. Ondra 2012/10/31 Lukas Barton <[email protected]>: > Pokud vim, tak nejde. Jedine co by mohlo pomoct je natural-key a criteria > API, ale nevim jestli je to tvuj pripad. > Dalsi moznost je udelat si aspekt, ktery navazu na volani DAO vrstvy a > transakce a ktery bude tak chytrej, ze vysledky bude cachovat tak jak bys to > chtel po Hibernatu. > > Do zapnuti L2 cache bych se nehrnul, protoze mit to spravne transakcne neni > uplne jednoduche. > > Jinak spravne reseni je prepsat aplikaci. Ono totiz vetsinou plati, ze v cim > vyssi vrstve se problem opravi, tim je to snazsi a vysledek je lepsi. > > > Lukas > > > > 2012/10/31 Ondra Medek <[email protected]> >> >> Ahoj, >> >> jde nejak kesovat query v Hibernate 1st level cache (session)? Behem >> prace s jednou session se generuje cca 2000 dotazu pres Query, ktere >> maji temer stejne parametry, takze se nakonec jedna pouze o cca 10 >> ruznych dotazu. A take vzhledem k pomalejsimu spojeni na DB (s tim nic >> nenadelam) to dost zdrzuje. >> >> Radeji bych to resil obecne takto pres Hibernate nez pres vlastni >> kesovani i vzhledem k dalsim implementacnim detailum v aplikaci. >> >> Diky >> -- >> Ondra Medek > > -- Ondra Medek
