geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianny Damour <gianny.dam...@optusnet.com.au>
Subject Re: gcache imlementation ideas[long]
Date Mon, 16 Oct 2006 14:01:07 GMT
Hi,

I think such an API will start to be useful for people interested to  
implement distributed or clustered services. At this stage, there is  
not a real need for such a capability; so, this may be a little bit  
premature to introduce it.

After some experiments with an API similar to the proposed one, I  
have reached the conclusion that the methods Node.getNodeAttributes  
and NodeListener.onNodeChange are not so great. Basically, you do not  
know which attributes have been changed and when they are propagated.  
So, if you had to write two services relying on nodeAttributes to  
exchange information, then the only way that I have been able to make  
such a thing work is to: timestamp each Map entry; check the  
existence of the entry you are interested in to filter out the  
irrelevant nodeChange events; store somewhere the timestamp of the  
last processed entry; and compare the timestamp of the Map entry with  
the one of the last processed entry. There are more elegant  
solutions; yet they require custom code on top of the API, which  
should simplify developers' life.

Thanks,
Gianny

On 12/10/2006, at 7:44 AM, Filip Hanik - Dev Lists wrote:

>
> I addressed the discussion about "what transport" do we use, a long  
> time ago by creating an agnostic API to plug into.
> http://marc.theaimsgroup.com/?l=geronimo-dev&m=115281186718399&w=2
> http://people.apache.org/~fhanik/geronimo-cluster-api.zip
>
> this way, we can continue the "pluggability" of G, and not pushing  
> any specific protocols.
> but writing a custom one just for G doesn't sound like a sound  
> solution
>
> in addition to ehcache, I'd like to propose that we take a look at  
> ASF's JCS(Java Cache System) which sits under the Jakarta umbrella.
> http://jakarta.apache.org/jcs/index.html
>
> and a performance report http://jakarta.apache.org/jcs/ 
> JCSvsEHCache.html (could be outdated)
>
> sorry about splitting up the gcache discussion, actually it was  
> already split when we started talking about the transport a while  
> back in this thread.
> However, my take on it is that we should use code already written,  
> while this is all really cool stuff to work on, creating a  
> distributed cache from start is hard and takes a very long time. I  
> would think the main goal is to get to JEE 5 right now.
>
>
> Filip


Mime
View raw message