Yep, that ehcache seems pretty sophisticated. However, I like the simplicity of memcached.
I am not particularly bound to Java, I think Java is a great language but has disadvantages in memory management and speed. I was merely referencing the trend of using more in-memory architectures which make sense these days. I think that trivial, performance critical tasks are better done using optimized native code and use high level environments to implement the business logic. It also would be great to conform to a well established interface standard that memcached has already in place. I found something called repcached which comes closest uptill now... I need to look into that. However, I might still be interested to develop some extension to memcached that implements transparent replication as described earlier. If someone sees caveats or has suggestions I am really really interested... On Jul 3, 11:38 pm, John Reilly <[email protected]> wrote: > If you are doing this in Java, you can use ehcache server. Actually, your > clients don't need to be java based. The last time I looked there were no > clients for doing the partitioning of requests to servers. I think there is > a diagram and description of this scenario on the ehcache web site. I'm not > using ehcache server myself though, so I can't say how good it is. I prefer > a combination of ehcache and memcache. > Cheers, > John > > On Fri, Jul 3, 2009 at 7:22 AM, sven bommezijn > <[email protected]>wrote: > > > > > Well, I do not want to kick against any religion, but in grid > > computing (like for example Java Spaces) memory is the new harddisk. > > Since memory gets cheaper and processors are becoming faster I think > > there IS some cause for a memcached like mechanism to be used in a > > distributed, replicated way. > > > I am thinking of a configuration where different memcached servers > > maintain a copy of themselves on secondary (or even more) machines. > > In the unlikely event of one primary server going down the client just > > refers to a secondary server. > > > Memcached entries might replicate themselves after a put or replace > > operation is completed. > > Particularly when Memcached is used for sessions it is unlikely that a > > get operation will follow in the instant that a put or replace > > operation has completed on the same entry. > > > I realize that this takes up extra network bandwidth and cycles but it > > definately offers an interesting mechanism for load balanced > > webservers hitting the same cache to retrieve session data. And if I > > am not mistaken such an architecture would still be of O(1), that is > > it still would grow lineairly with web traffic. > > > Anyone interested in a discussion about this? seems a nice optional > > feature for Memcached.
