ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From -dk- <dmitriy.kargapo...@gmail.com>
Subject cleaning select cache
Date Tue, 08 Dec 2009 21:41:59 GMT

Hi All,
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/cleaning-select-cache-tp26701284p26701284.html
Sent from the iBATIS - User - Java mailing list archive at Nabble.com.

To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org

View raw message