ibatis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clinton Begin <clinton.be...@gmail.com>
Subject Re: 1st level cache control
Date Thu, 10 Dec 2009 20:44:00 GMT
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.


On Thu, Dec 10, 2009 at 9:07 AM, -dk- <dmitriy.kargapolov@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-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: dev-help@ibatis.apache.org

View raw message