Skip to main content

Project Idea: memcached JSF Component

Posted by edburns on November 23, 2009 at 12:14 PM PST

While speaking at the href="http://twitter.com/search?q=%23tdc2009rio">Globalcode Developer's
conference in Rio de Janeiro, I met a dynamic and intelligent
student by the name of Thiago
Diogo
. Thiaogo presented his group's work on student project to
provide a real, mission critical distributed application for his
university, Universidade Federal
Fulminense
. They chose JSF 1.2 and Seam as a part of their stack.

One idea Thiaogo shared with me was a memcached JSF component. We
kicked the idea around and I mentioned it would be pretty easy to invent
a JSF component that acted like a <span> tag that
simply meant, “the rendered output of any JSF components inside of
me should come from memcached, if possible”. I don't have time to
start on this idea right now, so I thought I'd share it out here in my
blog in case anyone else wanted to pick it up, or if anyone else has
already done this! When I get time, I'll try adding it to the Mojarra
sandbox components, but in the meantime, anyone can have at it!

Technorati Tags:

Comments

Cache taglibs

check out this for example: http://www.servletsuite.com/servlets/cachetag.htm

Re: Cache taglibs

Awesome. Is there any chance you could make a Facelet version of it?

Thanks to remember!

Hi Ed, thanks for the mention in your blog about the idea. My team want to help you with the development of this component. Here in our project we've created a @CacheResult annotation to be placed at the service's methods (we use the App Service pattern) to store in one memcached instance the return of that method for next calls. We can think in something like this to the creation of our component.
How can I and my team get involved with this component development?
Again, thanks for remember the idea. And we're waiting you here in Olympic Games 2016!
See you.

Use a neutral API

Ed, one of the components we have always had in Seam was the tag, which rendered any nested tags using cached output (we never ventured into allowing input components inside these regions, not sure if that is something you are envisaging?). Anyway, a mistake we made early on was to essentially tie the component to the JBoss Cache API (which we later retrofitted to a generic API). As a result I would recommend not tying yourself to any particular API, but instead use a neutral one. In general, Map is a great fit for a cache access (and maybe ConcurrentMap for adding stuff to the cache), so I would suggest using that. You could then provide a default implementation based on memcached (which is definitely a pseudo-standard API :-)