>> Session Level Cache ... does not work if the data has been changed by >> another process
The session level cache is exactly that... session level. It only clears things local to your session. If another process changes data, you should have cache flushing rules in place to cause the cache to flush upon writing. This is no different than iBATIS 2.0. >> sharing sql sessions across threads Neither iBATIS 2 or 3 are safe to share sessions between threads. If it's working for you in iBATIS 2, you're getting lucky, and it will fail some day. iBATIS 2 had the SqlMapClient, which was "thread safe" because it used a ThreadLocal variable to manage the sessions for you. But the sessions themselves are not thread safe. iBATIS 3 has done away with the ThreadLocal API, in favor of better practices like Dependency Injection. But it would take all of 30 seconds for you to create your own ThreadLocal manager (you could practically copy the iBATIS 2.0 SqlMapClient). But definitely review your code to ensure you're not sharing sessions across threads... Session == Connection... so that's that's very bad. Cheers, Clinton 2010/3/4 François Schiettecatte <fschietteca...@gmail.com>: > Hi > > I have been migrating a project from ibatis 2 to 3 and have run into some > issues, mostly to do with connection pool management (C3P0), and I will write > up my notes on my blog once I am done. > > Two issues specifically with the Session Level Cache: > > --------- > Clearing the Session Level Cache > > void clearCache() > > The SqlSession instance has a local cache that is cleared upon update, > commit, rollback and close. To close it explicitly (perhaps with the > intention to do more work), you can call clearCache(). > --------- > > One issue is that it seems to cache selects which does not work if the data > has been changed by another process, running the select again in the same > session returns stale data. > > The other problem has to do with sharing sql sessions across threads (which > worked fine in 2). Running multiple selects through the same session gives me > casting errors generated by line 88 in BaseExecutor: > > localCache.putObject(key, EXECUTION_PLACEHOLDER); > > What seems to be happening is that the same query is coming in on one thread > and generates a hit on the localCache before the search is done on another > thread. > > Note that I am using C3P0 here which recommends caching sessions as much as > possible and it could be that I am not using the stack correctly, but what I > was doing worked fine in 2.x under heavy load. > > Cheers > > François > > > -- > François Schiettecatte > 35 Washington Square North, #2 > Salem, MA, 01970 > 617-909-2504 > http://fschiettecatte.wordpress.com/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org > For additional commands, e-mail: user-java-h...@ibatis.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org For additional commands, e-mail: user-java-h...@ibatis.apache.org
