Re: Possible race condition using org.apache.ibatis.cache.Cache#hasKey ?

[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