1st level cache control

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

1st level cache control

-dk-
Hi All,
Sorry, if anybody got this twice, I just decided that iBatis - Dev is better place for my question.

I confused when couldn't find any control over the 1st-level cache which is always On for select mapper.
What I found (thanks to open source) that easy way to do clean the cache is to call session.commit() (or rollback).

I use scenario when session stays open for some time and I need to monitor some value returned by select mapper.
This value is changed by other party, so all I need - just dirty read periodically. Not wasting time on session opening and closing.
So it appears that there is no "dirty ops" approach and I have to call commit/rollback between subsequent select in order to get updated value from the db.

Was this initial intention or just oversighted?

Would be nice to have something way to turn cache off or to clean it on demand. Using commit/rollback even in read-only context seems to be not smart solution.

Thank you!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 1st level cache control

Clinton Begin
It's not an oversight, and is definitely by design. 

It's built on the premise that it's a very bad idea to keep sessions open for any length of time. 

Cheers,
Clinton

On Thu, Dec 10, 2009 at 9:07 AM, -dk- <[hidden email]> wrote:

Hi All,
Sorry, if anybody got this twice, I just decided that iBatis - Dev is better
place for my question.

I confused when couldn't find any control over the 1st-level cache which is
always On for select mapper.
What I found (thanks to open source) that easy way to do clean the cache is
to call session.commit() (or rollback).

I use scenario when session stays open for some time and I need to monitor
some value returned by select mapper.
This value is changed by other party, so all I need - just dirty read
periodically. Not wasting time on session opening and closing.
So it appears that there is no "dirty ops" approach and I have to call
commit/rollback between subsequent select in order to get updated value from
the db.

Was this initial intention or just oversighted?

Would be nice to have something way to turn cache off or to clean it on
demand. Using commit/rollback even in read-only context seems to be not
smart solution.

Thank you!

--
View this message in context: http://old.nabble.com/1st-level-cache-control-tp26729953p26729953.html
Sent from the iBATIS - Dev mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Loading...