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