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 > >
