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: dev-unsubscr...@ibatis.apache.org For additional commands, e-mail: dev-h...@ibatis.apache.org
