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