ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clinton Begin <clinton.be...@gmail.com>
Subject Re: Possible race condition using org.apache.ibatis.cache.Cache#hasKey ?
Date Thu, 31 Dec 2009 16:11:28 GMT
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);


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?


On Thu, Dec 31, 2009 at 9:04 AM, Clinton Begin <clinton.begin@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

View raw message