You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by Clinton Begin <cl...@gmail.com> on 2010/03/04 15:22:08 UTC
Re: Migrating from ibatis 2 to 3
>> 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 <fs...@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-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: user-java-help@ibatis.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org
Re: ResultHandler
Posted by Clinton Begin <cl...@gmail.com>.
That's a good observation. Can you throw a feature request in jira?
Cheers,
Clinton
On 2010-03-05, François Schiettecatte <fs...@gmail.com> wrote:
> Hi
>
> Any reason why there are only two select() methods in
> org.apache.ibatis.session:
>
> void select(String statement, Object parameter, ResultHandler handler);
>
> void select(String statement, Object parameter, RowBounds rowBounds,
> ResultHandler handler);
>
>
> I would have expected to see this for symmetry with the others:
>
> void select(String statement, ResultHandler handler);
>
>
> Or should I just use a null in place of the object:
>
> sqlSession.select(statement, null, handler);
>
>
>
> Cheers
>
> François
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: user-java-help@ibatis.apache.org
>
>
--
Sent from my mobile device
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org
ResultHandler
Posted by François Schiettecatte <fs...@gmail.com>.
Hi
Any reason why there are only two select() methods in org.apache.ibatis.session:
void select(String statement, Object parameter, ResultHandler handler);
void select(String statement, Object parameter, RowBounds rowBounds, ResultHandler handler);
I would have expected to see this for symmetry with the others:
void select(String statement, ResultHandler handler);
Or should I just use a null in place of the object:
sqlSession.select(statement, null, handler);
Cheers
François
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org
Re: Migrating from ibatis 2 to 3
Posted by Clinton Begin <cl...@gmail.com>.
As I said, it's fine to share sqlmapclient... But not sessions.
And you wouldn't have to modify iB3 to implement a a multi-thread
capable sqlmapclient-like class.
Clinton
On 2010-03-04, François Schiettecatte <fs...@gmail.com> wrote:
> 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 <fs...@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-unsubscribe@ibatis.apache.org
>>> For additional commands, e-mail: user-java-help@ibatis.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>> For additional commands, e-mail: user-java-help@ibatis.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: user-java-help@ibatis.apache.org
>
>
--
Sent from my mobile device
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org
Re: Migrating from ibatis 2 to 3
Posted by François Schiettecatte <fs...@gmail.com>.
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 <fs...@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-unsubscribe@ibatis.apache.org
>> For additional commands, e-mail: user-java-help@ibatis.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: user-java-help@ibatis.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org