You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ibatis.apache.org by Simone Tripodi <si...@gmail.com> on 2009/12/31 13:38:50 UTC
Possible race condition using org.apache.ibatis.cache.Cache#hasKey ?
Hi all guys,
since I've been integrating 3rd part caching solutions[1] in iBatis3,
I started thinking about the use of method in the Cache interface:
org.apache.ibatis.cache.Cache#hasKey()
Honestly, I'm a little scared about the use for a key check, as it may
expire between checking for the key, and whatever you want to do with
the stored object, and produce a race condition :(
I'd propose to remove this method, and let to the layer built on top
of cache interface checking if the retrieved object is not null.
Indeed, some distribuited and scalable caching servers like
memcached[2] don't provide methods to key checking, because of the
reason above. Moreover, in this scenario, the only way I have to check
if a key is present in the cache, is getting the object, and checking
it is null. But let's suppose I've a cached Object of 10M size,
checking first and then getting if present, causes 20M net traffic :(
Please don't get me wrong, I don't want to criticize the excellent
work you've been doing - I don't use different persistence layer than
iBatis! - but since iBatis is largely used in production environments,
I would encourage the community to be sensible to this kind of
potential issues.
What do you think about it? Have a nice end of the year party and see
you next year! :D
Best regards,
Simone Tripodi
[1] http://ibaguice.googlecode.com/svn/site/1.0-SNAPSHOT/caching.html
[2] http://memcached.org/
--
http://www.google.com/profiles/simone.tripodi
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ibatis.apache.org
For additional commands, e-mail: dev-help@ibatis.apache.org
Re: Possible race condition using org.apache.ibatis.cache.Cache#hasKey
?
Posted by Simone Tripodi <si...@gmail.com>.
Hi Clinton,
I just open a Jira issue about this topic, you can find it on
https://issues.apache.org/jira/browse/IBATIS-724
Best regards and happy new year!
Simone
On Thu, Dec 31, 2009 at 11:09 PM, Simone Tripodi
<si...@gmail.com> wrote:
> ROFL, I feel so nerd, I should restart learning _natural_ languages
> and having more social life :D
> HAPPY 2010!!!
>
> On Thu, Dec 31, 2009 at 7:53 PM, Clinton Begin <cl...@gmail.com> wrote:
>> LOL... it was pseudocode in the middle of a sentence dude. :-)
>>
>>
>>
>> On Thu, Dec 31, 2009 at 11:29 AM, Simone Tripodi <si...@gmail.com>
>> wrote:
>>>
>>> Hi Clinton,
>>> sure, I'll add the Jira ticket for this, but since here in Italy,
>>> because of the timezone, started celebrating the new year, I'll do it
>>> tomorrow :P
>>> BTW, I discourage the use of the test
>>>
>>> value == Cache.NULL_OBJECT
>>>
>>> but rather
>>>
>>> Cache.NULL_OBJECT.equals(vaue)
>>>
>>> I had to patch iBatis 2 (and reported to the dev ML, see
>>> http://markmail.org/message/lm752wxm2jwcpg5l), with this last check to
>>> use a distribuited cache. My scenario was: the same iBatis application
>>> replicated on more than one application server (on different servers)
>>> more than one memcached node server as cache storage. Moreover,
>>> Cache.NULL_OBJECT has to be Serializable.
>>>
>>> Happy new year and tanks for your replies!!! :)
>>> Best regards,
>>> Simone Tripodi
>>>
>>>
>>> On Thu, Dec 31, 2009 at 5:11 PM, Clinton Begin <cl...@gmail.com>
>>> wrote:
>>> > PS: I just had a look, and I doubt there's any chance of a race
>>> > condition
>>> > here... there's only two usages of hasKey(). One is thread local, and
>>> > the
>>> > other uses a read/write lock scope.
>>> >
>>> > That said, I think your point about performance is perfectly warranted,
>>> > and
>>> > quite simple to solve. For example:
>>> >
>>> > if (cache.hasKey(key)) {
>>> > return (List) cache.getObject(key);
>>> > }...
>>> >
>>> > Becomes:
>>> >
>>> > Object value = cache.getObject(key)
>>> > if (value != null) {
>>> > return Cache.isNull(value) ? null : value;
>>> > }...
>>> >
>>> > Where Cache.isNull(value) simply checks if value == Cache.NULL_OBJECT.
>>> > Of
>>> > course you could just do that outside too, but I think having a method
>>> > like
>>> > this makes it nicer to read.
>>> >
>>> > Do you want to add a Jira ticket for this?
>>> >
>>> > Clinton
>>> >
>>> > On Thu, Dec 31, 2009 at 9:04 AM, Clinton Begin <cl...@gmail.com>
>>> > wrote:
>>> >>
>>> >> Good points.
>>> >>
>>> >> I think the only reason hasKey exists is to support cached null values.
>>> >> But that said, I believe in iBATIS 2 I used a NULL_OBJECT value to
>>> >> represent
>>> >> the difference between "yes I'm cached, and I'm null" vs. "I'm not
>>> >> cached".
>>> >>
>>> >> So I think there definitely is something to look at here.
>>> >>
>>> >> Clinton
>>> >>
>>> >> On Thu, Dec 31, 2009 at 5:38 AM, Simone Tripodi
>>> >> <si...@gmail.com>
>>> >> wrote:
>>> >>>
>>> >>> Hi all guys,
>>> >>> since I've been integrating 3rd part caching solutions[1] in iBatis3,
>>> >>> I started thinking about the use of method in the Cache interface:
>>> >>>
>>> >>> org.apache.ibatis.cache.Cache#hasKey()
>>> >>>
>>> >>> Honestly, I'm a little scared about the use for a key check, as it may
>>> >>> expire between checking for the key, and whatever you want to do with
>>> >>> the stored object, and produce a race condition :(
>>> >>> I'd propose to remove this method, and let to the layer built on top
>>> >>> of cache interface checking if the retrieved object is not null.
>>> >>>
>>> >>> Indeed, some distribuited and scalable caching servers like
>>> >>> memcached[2] don't provide methods to key checking, because of the
>>> >>> reason above. Moreover, in this scenario, the only way I have to check
>>> >>> if a key is present in the cache, is getting the object, and checking
>>> >>> it is null. But let's suppose I've a cached Object of 10M size,
>>> >>> checking first and then getting if present, causes 20M net traffic :(
>>> >>>
>>> >>> Please don't get me wrong, I don't want to criticize the excellent
>>> >>> work you've been doing - I don't use different persistence layer than
>>> >>> iBatis! - but since iBatis is largely used in production environments,
>>> >>> I would encourage the community to be sensible to this kind of
>>> >>> potential issues.
>>> >>>
>>> >>> What do you think about it? Have a nice end of the year party and see
>>> >>> you next year! :D
>>> >>> Best regards,
>>> >>> Simone Tripodi
>>> >>>
>>> >>> [1] http://ibaguice.googlecode.com/svn/site/1.0-SNAPSHOT/caching.html
>>> >>> [2] http://memcached.org/
>>> >>>
>>> >>> --
>>> >>> http://www.google.com/profiles/simone.tripodi
>>> >>>
>>> >>> ---------------------------------------------------------------------
>>> >>> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>>> >>> For additional commands, e-mail: user-java-help@ibatis.apache.org
>>> >>>
>>> >>
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> http://www.google.com/profiles/simone.tripodi
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>>> For additional commands, e-mail: user-java-help@ibatis.apache.org
>>>
>>
>>
>
>
>
> --
> http://www.google.com/profiles/simone.tripodi
>
--
http://www.google.com/profiles/simone.tripodi
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org
Re: Possible race condition using org.apache.ibatis.cache.Cache#hasKey
?
Posted by Simone Tripodi <si...@gmail.com>.
ROFL, I feel so nerd, I should restart learning _natural_ languages
and having more social life :D
HAPPY 2010!!!
On Thu, Dec 31, 2009 at 7:53 PM, Clinton Begin <cl...@gmail.com> wrote:
> LOL... it was pseudocode in the middle of a sentence dude. :-)
>
>
>
> On Thu, Dec 31, 2009 at 11:29 AM, Simone Tripodi <si...@gmail.com>
> wrote:
>>
>> Hi Clinton,
>> sure, I'll add the Jira ticket for this, but since here in Italy,
>> because of the timezone, started celebrating the new year, I'll do it
>> tomorrow :P
>> BTW, I discourage the use of the test
>>
>> value == Cache.NULL_OBJECT
>>
>> but rather
>>
>> Cache.NULL_OBJECT.equals(vaue)
>>
>> I had to patch iBatis 2 (and reported to the dev ML, see
>> http://markmail.org/message/lm752wxm2jwcpg5l), with this last check to
>> use a distribuited cache. My scenario was: the same iBatis application
>> replicated on more than one application server (on different servers)
>> more than one memcached node server as cache storage. Moreover,
>> Cache.NULL_OBJECT has to be Serializable.
>>
>> Happy new year and tanks for your replies!!! :)
>> Best regards,
>> Simone Tripodi
>>
>>
>> On Thu, Dec 31, 2009 at 5:11 PM, Clinton Begin <cl...@gmail.com>
>> wrote:
>> > PS: I just had a look, and I doubt there's any chance of a race
>> > condition
>> > here... there's only two usages of hasKey(). One is thread local, and
>> > the
>> > other uses a read/write lock scope.
>> >
>> > That said, I think your point about performance is perfectly warranted,
>> > and
>> > quite simple to solve. For example:
>> >
>> > if (cache.hasKey(key)) {
>> > return (List) cache.getObject(key);
>> > }...
>> >
>> > Becomes:
>> >
>> > Object value = cache.getObject(key)
>> > if (value != null) {
>> > return Cache.isNull(value) ? null : value;
>> > }...
>> >
>> > Where Cache.isNull(value) simply checks if value == Cache.NULL_OBJECT.
>> > Of
>> > course you could just do that outside too, but I think having a method
>> > like
>> > this makes it nicer to read.
>> >
>> > Do you want to add a Jira ticket for this?
>> >
>> > Clinton
>> >
>> > On Thu, Dec 31, 2009 at 9:04 AM, Clinton Begin <cl...@gmail.com>
>> > wrote:
>> >>
>> >> Good points.
>> >>
>> >> I think the only reason hasKey exists is to support cached null values.
>> >> But that said, I believe in iBATIS 2 I used a NULL_OBJECT value to
>> >> represent
>> >> the difference between "yes I'm cached, and I'm null" vs. "I'm not
>> >> cached".
>> >>
>> >> So I think there definitely is something to look at here.
>> >>
>> >> Clinton
>> >>
>> >> On Thu, Dec 31, 2009 at 5:38 AM, Simone Tripodi
>> >> <si...@gmail.com>
>> >> wrote:
>> >>>
>> >>> Hi all guys,
>> >>> since I've been integrating 3rd part caching solutions[1] in iBatis3,
>> >>> I started thinking about the use of method in the Cache interface:
>> >>>
>> >>> org.apache.ibatis.cache.Cache#hasKey()
>> >>>
>> >>> Honestly, I'm a little scared about the use for a key check, as it may
>> >>> expire between checking for the key, and whatever you want to do with
>> >>> the stored object, and produce a race condition :(
>> >>> I'd propose to remove this method, and let to the layer built on top
>> >>> of cache interface checking if the retrieved object is not null.
>> >>>
>> >>> Indeed, some distribuited and scalable caching servers like
>> >>> memcached[2] don't provide methods to key checking, because of the
>> >>> reason above. Moreover, in this scenario, the only way I have to check
>> >>> if a key is present in the cache, is getting the object, and checking
>> >>> it is null. But let's suppose I've a cached Object of 10M size,
>> >>> checking first and then getting if present, causes 20M net traffic :(
>> >>>
>> >>> Please don't get me wrong, I don't want to criticize the excellent
>> >>> work you've been doing - I don't use different persistence layer than
>> >>> iBatis! - but since iBatis is largely used in production environments,
>> >>> I would encourage the community to be sensible to this kind of
>> >>> potential issues.
>> >>>
>> >>> What do you think about it? Have a nice end of the year party and see
>> >>> you next year! :D
>> >>> Best regards,
>> >>> Simone Tripodi
>> >>>
>> >>> [1] http://ibaguice.googlecode.com/svn/site/1.0-SNAPSHOT/caching.html
>> >>> [2] http://memcached.org/
>> >>>
>> >>> --
>> >>> http://www.google.com/profiles/simone.tripodi
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>> >>> For additional commands, e-mail: user-java-help@ibatis.apache.org
>> >>>
>> >>
>> >
>> >
>>
>>
>>
>> --
>> http://www.google.com/profiles/simone.tripodi
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>> For additional commands, e-mail: user-java-help@ibatis.apache.org
>>
>
>
--
http://www.google.com/profiles/simone.tripodi
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org
Re: Possible race condition using org.apache.ibatis.cache.Cache#hasKey
?
Posted by Clinton Begin <cl...@gmail.com>.
LOL... it was pseudocode in the middle of a sentence dude. :-)
On Thu, Dec 31, 2009 at 11:29 AM, Simone Tripodi
<si...@gmail.com>wrote:
> Hi Clinton,
> sure, I'll add the Jira ticket for this, but since here in Italy,
> because of the timezone, started celebrating the new year, I'll do it
> tomorrow :P
> BTW, I discourage the use of the test
>
> value == Cache.NULL_OBJECT
>
> but rather
>
> Cache.NULL_OBJECT.equals(vaue)
>
> I had to patch iBatis 2 (and reported to the dev ML, see
> http://markmail.org/message/lm752wxm2jwcpg5l), with this last check to
> use a distribuited cache. My scenario was: the same iBatis application
> replicated on more than one application server (on different servers)
> more than one memcached node server as cache storage. Moreover,
> Cache.NULL_OBJECT has to be Serializable.
>
> Happy new year and tanks for your replies!!! :)
> Best regards,
> Simone Tripodi
>
>
> On Thu, Dec 31, 2009 at 5:11 PM, Clinton Begin <cl...@gmail.com>
> wrote:
> > PS: I just had a look, and I doubt there's any chance of a race
> condition
> > here... there's only two usages of hasKey(). One is thread local, and
> the
> > other uses a read/write lock scope.
> >
> > That said, I think your point about performance is perfectly warranted,
> and
> > quite simple to solve. For example:
> >
> > if (cache.hasKey(key)) {
> > return (List) cache.getObject(key);
> > }...
> >
> > Becomes:
> >
> > Object value = cache.getObject(key)
> > if (value != null) {
> > return Cache.isNull(value) ? null : value;
> > }...
> >
> > Where Cache.isNull(value) simply checks if value == Cache.NULL_OBJECT.
> Of
> > course you could just do that outside too, but I think having a method
> like
> > this makes it nicer to read.
> >
> > Do you want to add a Jira ticket for this?
> >
> > Clinton
> >
> > On Thu, Dec 31, 2009 at 9:04 AM, Clinton Begin <cl...@gmail.com>
> > wrote:
> >>
> >> Good points.
> >>
> >> I think the only reason hasKey exists is to support cached null values.
> >> But that said, I believe in iBATIS 2 I used a NULL_OBJECT value to
> represent
> >> the difference between "yes I'm cached, and I'm null" vs. "I'm not
> cached".
> >>
> >> So I think there definitely is something to look at here.
> >>
> >> Clinton
> >>
> >> On Thu, Dec 31, 2009 at 5:38 AM, Simone Tripodi <
> simone.tripodi@gmail.com>
> >> wrote:
> >>>
> >>> Hi all guys,
> >>> since I've been integrating 3rd part caching solutions[1] in iBatis3,
> >>> I started thinking about the use of method in the Cache interface:
> >>>
> >>> org.apache.ibatis.cache.Cache#hasKey()
> >>>
> >>> Honestly, I'm a little scared about the use for a key check, as it may
> >>> expire between checking for the key, and whatever you want to do with
> >>> the stored object, and produce a race condition :(
> >>> I'd propose to remove this method, and let to the layer built on top
> >>> of cache interface checking if the retrieved object is not null.
> >>>
> >>> Indeed, some distribuited and scalable caching servers like
> >>> memcached[2] don't provide methods to key checking, because of the
> >>> reason above. Moreover, in this scenario, the only way I have to check
> >>> if a key is present in the cache, is getting the object, and checking
> >>> it is null. But let's suppose I've a cached Object of 10M size,
> >>> checking first and then getting if present, causes 20M net traffic :(
> >>>
> >>> Please don't get me wrong, I don't want to criticize the excellent
> >>> work you've been doing - I don't use different persistence layer than
> >>> iBatis! - but since iBatis is largely used in production environments,
> >>> I would encourage the community to be sensible to this kind of
> >>> potential issues.
> >>>
> >>> What do you think about it? Have a nice end of the year party and see
> >>> you next year! :D
> >>> Best regards,
> >>> Simone Tripodi
> >>>
> >>> [1] http://ibaguice.googlecode.com/svn/site/1.0-SNAPSHOT/caching.html
> >>> [2] http://memcached.org/
> >>>
> >>> --
> >>> http://www.google.com/profiles/simone.tripodi
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> >>> For additional commands, e-mail: user-java-help@ibatis.apache.org
> >>>
> >>
> >
> >
>
>
>
> --
> http://www.google.com/profiles/simone.tripodi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: user-java-help@ibatis.apache.org
>
>
Re: Possible race condition using org.apache.ibatis.cache.Cache#hasKey
?
Posted by Simone Tripodi <si...@gmail.com>.
Hi Clinton,
sure, I'll add the Jira ticket for this, but since here in Italy,
because of the timezone, started celebrating the new year, I'll do it
tomorrow :P
BTW, I discourage the use of the test
value == Cache.NULL_OBJECT
but rather
Cache.NULL_OBJECT.equals(vaue)
I had to patch iBatis 2 (and reported to the dev ML, see
http://markmail.org/message/lm752wxm2jwcpg5l), with this last check to
use a distribuited cache. My scenario was: the same iBatis application
replicated on more than one application server (on different servers)
more than one memcached node server as cache storage. Moreover,
Cache.NULL_OBJECT has to be Serializable.
Happy new year and tanks for your replies!!! :)
Best regards,
Simone Tripodi
On Thu, Dec 31, 2009 at 5:11 PM, Clinton Begin <cl...@gmail.com> wrote:
> PS: I just had a look, and I doubt there's any chance of a race condition
> here... there's only two usages of hasKey(). One is thread local, and the
> other uses a read/write lock scope.
>
> That said, I think your point about performance is perfectly warranted, and
> quite simple to solve. For example:
>
> if (cache.hasKey(key)) {
> return (List) cache.getObject(key);
> }...
>
> Becomes:
>
> Object value = cache.getObject(key)
> if (value != null) {
> return Cache.isNull(value) ? null : value;
> }...
>
> Where Cache.isNull(value) simply checks if value == Cache.NULL_OBJECT. Of
> course you could just do that outside too, but I think having a method like
> this makes it nicer to read.
>
> Do you want to add a Jira ticket for this?
>
> Clinton
>
> On Thu, Dec 31, 2009 at 9:04 AM, Clinton Begin <cl...@gmail.com>
> wrote:
>>
>> Good points.
>>
>> I think the only reason hasKey exists is to support cached null values.
>> But that said, I believe in iBATIS 2 I used a NULL_OBJECT value to represent
>> the difference between "yes I'm cached, and I'm null" vs. "I'm not cached".
>>
>> So I think there definitely is something to look at here.
>>
>> Clinton
>>
>> On Thu, Dec 31, 2009 at 5:38 AM, Simone Tripodi <si...@gmail.com>
>> wrote:
>>>
>>> Hi all guys,
>>> since I've been integrating 3rd part caching solutions[1] in iBatis3,
>>> I started thinking about the use of method in the Cache interface:
>>>
>>> org.apache.ibatis.cache.Cache#hasKey()
>>>
>>> Honestly, I'm a little scared about the use for a key check, as it may
>>> expire between checking for the key, and whatever you want to do with
>>> the stored object, and produce a race condition :(
>>> I'd propose to remove this method, and let to the layer built on top
>>> of cache interface checking if the retrieved object is not null.
>>>
>>> Indeed, some distribuited and scalable caching servers like
>>> memcached[2] don't provide methods to key checking, because of the
>>> reason above. Moreover, in this scenario, the only way I have to check
>>> if a key is present in the cache, is getting the object, and checking
>>> it is null. But let's suppose I've a cached Object of 10M size,
>>> checking first and then getting if present, causes 20M net traffic :(
>>>
>>> Please don't get me wrong, I don't want to criticize the excellent
>>> work you've been doing - I don't use different persistence layer than
>>> iBatis! - but since iBatis is largely used in production environments,
>>> I would encourage the community to be sensible to this kind of
>>> potential issues.
>>>
>>> What do you think about it? Have a nice end of the year party and see
>>> you next year! :D
>>> Best regards,
>>> Simone Tripodi
>>>
>>> [1] http://ibaguice.googlecode.com/svn/site/1.0-SNAPSHOT/caching.html
>>> [2] http://memcached.org/
>>>
>>> --
>>> http://www.google.com/profiles/simone.tripodi
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>>> For additional commands, e-mail: user-java-help@ibatis.apache.org
>>>
>>
>
>
--
http://www.google.com/profiles/simone.tripodi
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org
Re: Possible race condition using org.apache.ibatis.cache.Cache#hasKey
?
Posted by Clinton Begin <cl...@gmail.com>.
PS: I just had a look, and I doubt there's any chance of a race condition
here... there's only two usages of hasKey(). One is thread local, and the
other uses a read/write lock scope.
That said, I think your point about performance is perfectly warranted, and
quite simple to solve. For example:
if (cache.hasKey(key)) {
return (List) cache.getObject(key);
}...
Becomes:
Object value = cache.getObject(key)
if (value != null) {
return Cache.isNull(value) ? null : value;
}...
Where Cache.isNull(value) simply checks if value == Cache.NULL_OBJECT. Of
course you could just do that outside too, but I think having a method like
this makes it nicer to read.
Do you want to add a Jira ticket for this?
Clinton
On Thu, Dec 31, 2009 at 9:04 AM, Clinton Begin <cl...@gmail.com>wrote:
> Good points.
>
> I think the only reason hasKey exists is to support cached null values.
> But that said, I believe in iBATIS 2 I used a NULL_OBJECT value to represent
> the difference between "yes I'm cached, and I'm null" vs. "I'm not cached".
>
> So I think there definitely is something to look at here.
>
> Clinton
>
>
> On Thu, Dec 31, 2009 at 5:38 AM, Simone Tripodi <si...@gmail.com>wrote:
>
>> Hi all guys,
>> since I've been integrating 3rd part caching solutions[1] in iBatis3,
>> I started thinking about the use of method in the Cache interface:
>>
>> org.apache.ibatis.cache.Cache#hasKey()
>>
>> Honestly, I'm a little scared about the use for a key check, as it may
>> expire between checking for the key, and whatever you want to do with
>> the stored object, and produce a race condition :(
>> I'd propose to remove this method, and let to the layer built on top
>> of cache interface checking if the retrieved object is not null.
>>
>> Indeed, some distribuited and scalable caching servers like
>> memcached[2] don't provide methods to key checking, because of the
>> reason above. Moreover, in this scenario, the only way I have to check
>> if a key is present in the cache, is getting the object, and checking
>> it is null. But let's suppose I've a cached Object of 10M size,
>> checking first and then getting if present, causes 20M net traffic :(
>>
>> Please don't get me wrong, I don't want to criticize the excellent
>> work you've been doing - I don't use different persistence layer than
>> iBatis! - but since iBatis is largely used in production environments,
>> I would encourage the community to be sensible to this kind of
>> potential issues.
>>
>> What do you think about it? Have a nice end of the year party and see
>> you next year! :D
>> Best regards,
>> Simone Tripodi
>>
>> [1] http://ibaguice.googlecode.com/svn/site/1.0-SNAPSHOT/caching.html
>> [2] http://memcached.org/
>>
>> --
>> http://www.google.com/profiles/simone.tripodi
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>> For additional commands, e-mail: user-java-help@ibatis.apache.org
>>
>>
>
Re: Possible race condition using org.apache.ibatis.cache.Cache#hasKey
?
Posted by Clinton Begin <cl...@gmail.com>.
Good points.
I think the only reason hasKey exists is to support cached null values.
But that said, I believe in iBATIS 2 I used a NULL_OBJECT value to represent
the difference between "yes I'm cached, and I'm null" vs. "I'm not cached".
So I think there definitely is something to look at here.
Clinton
On Thu, Dec 31, 2009 at 5:38 AM, Simone Tripodi <si...@gmail.com>wrote:
> Hi all guys,
> since I've been integrating 3rd part caching solutions[1] in iBatis3,
> I started thinking about the use of method in the Cache interface:
>
> org.apache.ibatis.cache.Cache#hasKey()
>
> Honestly, I'm a little scared about the use for a key check, as it may
> expire between checking for the key, and whatever you want to do with
> the stored object, and produce a race condition :(
> I'd propose to remove this method, and let to the layer built on top
> of cache interface checking if the retrieved object is not null.
>
> Indeed, some distribuited and scalable caching servers like
> memcached[2] don't provide methods to key checking, because of the
> reason above. Moreover, in this scenario, the only way I have to check
> if a key is present in the cache, is getting the object, and checking
> it is null. But let's suppose I've a cached Object of 10M size,
> checking first and then getting if present, causes 20M net traffic :(
>
> Please don't get me wrong, I don't want to criticize the excellent
> work you've been doing - I don't use different persistence layer than
> iBatis! - but since iBatis is largely used in production environments,
> I would encourage the community to be sensible to this kind of
> potential issues.
>
> What do you think about it? Have a nice end of the year party and see
> you next year! :D
> Best regards,
> Simone Tripodi
>
> [1] http://ibaguice.googlecode.com/svn/site/1.0-SNAPSHOT/caching.html
> [2] http://memcached.org/
>
> --
> http://www.google.com/profiles/simone.tripodi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: user-java-help@ibatis.apache.org
>
>