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 <simone.trip...@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 <clinton.be...@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 <simone.trip...@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 <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 >>> >> >> > > > > -- > http://www.google.com/profiles/simone.tripodi > -- 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
