Wednesday, February 23, 2005

Stateful vs Stateless SessionBeans in Clustered Env

We had a heated debate about some implementation decisions for this new project here at work. The final application will be clustered, so with that you essentially have no choice but to go stateless in all your session beans, or else you're locked into one node in the cluster (and that's not good).

**NEWS FLASH** it's been decided that we'll be using Tangosol's Coherence as a distributed caching solution (previous blog mentioned the competing bids of Coherence vs Gigaspaces).

Well, SLSB's are fine and dandy in theory but there *are* going to be places where you need state. A couple of people gasped when it was suggested that we needed state in a few places and from there the discussion went back to the topic of "but in the holy grail of clustered environments, we CANNOT have state".

So, by the end of the meeting it dawned on me (and everyone seemed to agree), that we could just use SLSB everywhere and the places you need a SFSB, implement it with a SLSB+Coherence. Now obviously there will be quirks that need to be dealt with but from a theoretical point of view, it seems perfect. The hybrid solution to stateless and stateful session beans.

If others have done similar things, please comment so we can avoid any common mistakes.

3 comments:

Anonymous said...

You will need to watch youir performance closely. Try to acheive stickyness - if the server goes down, the client can fail over, but by default it should stick to the same server.

Anonymous said...

Glad to hear that you are going to be using Coherence :-)

Anonymous said...
This comment has been removed by a blog administrator.