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 <clinton.be...@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 <clinton.be...@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.trip...@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-unsubscr...@ibatis.apache.org
>>> For additional commands, e-mail: user-java-h...@ibatis.apache.org
>>>
>>
>
>



-- 
http://www.google.com/profiles/simone.tripodi

---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org
For additional commands, e-mail: user-java-h...@ibatis.apache.org

Reply via email to