Re: FIX?: protected static ThreadLocal localSqlMapSession = new ThreadLocal();
Here's a quick summary that we could add to the docs, and maybe offer a simpler config for... LOCAL_READ_WRITE (serializable=false, readOnly=false) SHARED_READ_ONLY (serializable=false, readOnly=true) SHARED_READ_WRITE (serializable=true, readOnly=false) Sorry for the dip-switch like interface... remember those? :-) Clinton On Fri, Jul 11, 2008 at 3:52 PM, Vic Cekvenich <[EMAIL PROTECTED]> wrote: > (read-only=false does not cache). > > So serialize="true" works, but not all the time. I spent a few hours and > could not find a pattern of when/why it works sometimes and sometimes not. > The code patch works 100% of time for those that want that effect. > > I propose that in addition to docs, the code also be changed so that it can > be set via some property so it works reliably. If people think about it an > like that kind of a design I could work more to make it easier to apply the > potential patch. > > btw, the way I test is by turning sql logging in mysql to on. > .V > > > Larry Meadors wrote: > >> Make the cache read-only and serializable, and it will be container wide. >> >> >> >>> Before: >>> protected ThreadLocal localSqlMapSession = new ThreadLocal(); >>> After: >>> protected static ThreadLocal localSqlMapSession = new ThreadLocal(); >>> in SqlMapClientImpl >>> >>> >>> >> >
Re: FIX?: protected static ThreadLocal localSqlMapSession = new ThreadLocal();
(read-only=false does not cache). So serialize="true" works, but not all the time. I spent a few hours and could not find a pattern of when/why it works sometimes and sometimes not. The code patch works 100% of time for those that want that effect. I propose that in addition to docs, the code also be changed so that it can be set via some property so it works reliably. If people think about it an like that kind of a design I could work more to make it easier to apply the potential patch. btw, the way I test is by turning sql logging in mysql to on. .V Larry Meadors wrote: Make the cache read-only and serializable, and it will be container wide. Before: protected ThreadLocal localSqlMapSession = new ThreadLocal(); After: protected static ThreadLocal localSqlMapSession = new ThreadLocal(); in SqlMapClientImpl
Re: FIX?: protected static ThreadLocal localSqlMapSession = new ThreadLocal();
Docs I think say make read-only false, not leave true. So this is what I have: which works in most cases, but sometimes it does not. So what is it read-only=false as per docs or what you said? tia, .V Larry Meadors wrote: Make the cache read-only and serializable, and it will be container wide. Larry
Re: FIX?: protected static ThreadLocal localSqlMapSession = new ThreadLocal();
I just tried that and it seems to work, I will do further testing. (It be nice to use main trunk and not my fork). I propose a documentation patch (pg45 bottom): Before: Read-Only cache will not be serilized(ther's no benefit) After (words to the effect). iBatis caching defaults to user session cache only. A more advanced mode that will increase cache hits is to share a cache across users, which requires understanding transactions and stale data and flushing, may give you a huge performance increase at some staleness risk when you serialize="true". .V Larry Meadors wrote: Make the cache read-only and serializable, and it will be container wide. Larry On Fri, Jul 11, 2008 at 9:56 AM, Vic Cekvenich <[EMAIL PROTECTED]> wrote: Before: protected ThreadLocal localSqlMapSession = new ThreadLocal(); After: protected static ThreadLocal localSqlMapSession = new ThreadLocal(); in SqlMapClientImpl Rationale: People(me) expect the cache to be "container"(war) wide, and not "session" based. Ex: I have user1 pull put client 101,102,103, user2 pulls up 104 and 103: 103 should be in cache already, a cache hit. The FIX? should disable the cache checking the session as part of the key. At least it should be a "property" in "ibatis.xml" to turn on/off and some docs. I did this at a few ibatis deployments .V
Re: FIX?: protected static ThreadLocal localSqlMapSession = new ThreadLocal();
This is not the right fix for this problem (I suggest changing back those other deployments). Make the cache read-only or serializable... either will work. Note that simply making it read-only and then modifying the data (i.e. lying to the framework) will get you into trouble. The two settings are confusing and have been simplified in iBATIS 3 to simply: "ReadWrite" which must contain only serializable/immutable objects objects, or "ReadOnly", which can contain anything, but you are still responsible for not changing the data. Clinton On Fri, Jul 11, 2008 at 9:56 AM, Vic Cekvenich <[EMAIL PROTECTED]> wrote: > Before: > protected ThreadLocal localSqlMapSession = new ThreadLocal(); > After: > protected static ThreadLocal localSqlMapSession = new ThreadLocal(); > in SqlMapClientImpl > > Rationale: > People(me) expect the cache to be "container"(war) wide, and not "session" > based. Ex: I have user1 pull put client 101,102,103, user2 pulls up 104 and > 103: 103 should be in cache already, a cache hit. The FIX? should disable > the cache checking the session as part of the key. > At least it should be a "property" in "ibatis.xml" to turn on/off and some > docs. > > I did this at a few ibatis deployments > > > .V > >
Re: FIX?: protected static ThreadLocal localSqlMapSession = new ThreadLocal();
Make the cache read-only and serializable, and it will be container wide. Larry On Fri, Jul 11, 2008 at 9:56 AM, Vic Cekvenich <[EMAIL PROTECTED]> wrote: > Before: > protected ThreadLocal localSqlMapSession = new ThreadLocal(); > After: > protected static ThreadLocal localSqlMapSession = new ThreadLocal(); > in SqlMapClientImpl > > Rationale: > People(me) expect the cache to be "container"(war) wide, and not "session" > based. Ex: I have user1 pull put client 101,102,103, user2 pulls up 104 and > 103: 103 should be in cache already, a cache hit. The FIX? should disable > the cache checking the session as part of the key. > At least it should be a "property" in "ibatis.xml" to turn on/off and some > docs. > > I did this at a few ibatis deployments > > > .V > >
