Clinton Thanks for explaining that, much clearer now and it makes my code simpler. I know I *could* modify the iBATIS 3 code but I am loath to do that because it would introduce variability.
FWIW iBATIS 2 was completely stable sharing SqlMapClient, I had no issues for 18 months. Cheers François On Mar 4, 2010, at 9:22 AM, Clinton Begin wrote: >>> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org For additional commands, e-mail: user-java-h...@ibatis.apache.org
