Spring in clustered environment

[dwojtas]

Hi,

We are currently working on an application that works in a clustered environment (Session beans, EJB container).
In such environment a developer that uses a component doesn't have to think where it in fact resides. It's up to the container to spread components on clusters and return references to them. More clusters - change configuration of your container.

I wonder what it is like with Spring components.
Do I need any special container (like Weblogic/Websphere/Jonas for EJBs)?
Or maybe it can be done in different way?
What are the possibilities here?

If we decide that the next project uses Spring, how to manage/use clusters when there is demand for more power?

Dariusz Wojtas

[smccrory]

If you store state in the HttpSession, you'll want to use Websphere or something that will replicate it to other servers in the cluster, that way every request will be aware of the user's state regardless of which server processes it. Alternatively you could put a load balancer in front of the cluster and enable "sticky-sessions" so that each user sticks to the server they were initially routed to. Note these two strategies may also sway you to use different database caching strategies.

[Martin Kersten]

A clustered architecture can mean diffrent things.

We are currently working on an application that works in a clustered environment (Session beans, EJB container).
In such environment a developer that uses a component doesn't have to think where it in fact resides.

Beside the 'developer havent to where the component in fact resides' being a big performance/synchronization/concurrency problem, I think you are referring to a truly distributed system.

Distributed system usally means specialized nodes, travling objects, adaptive structure, grouping and so on. I don't know any of your requirements. And so I know zip about the constraints applying to your project. But having the specialization of my university study about distributed systems, I think I am able to tell you my point of view.

I think truly distributed systems are overhyped. There are only rare cases - I am aware of - which will require or profitate from a truly distributed architecture. Another possibility is using a co-located server structure. By using a co-located architecture, you can mostly simplify and ease development by some degrees.

* Co-located servers may use a single database for a given part of the model (collection of related tables), so the database is fully responsible for distributed transaction management, replication etc.

* You can use simple load-strategies like the one provided by apache.

* You may also use a common distributed cache implementation for replication of the session datas.

Since a session is only opened by the same server at a time, it is not required for any server to hold a replicated version of the session. Mostly it is enough to provide a little specialised co-located server collection (on to three servers) storing a version of the current sessions of each server. In case of server failover another server will be choosen by the load-strategy to process the client request. The new server will try to check if a session exists within the session store. The propability the server fails at the same time the session storing cluster also fails is very low. (check your constraints)


Summary:

Using a truly distributed architectures is more properly to be a burdon than a gain. There are only some small scenarios - I am aware of - which will profitate from a truly distributed architecture. All the advanced stuff like distributed transactions, object replication, network-traffic are more likely to prevent such a system from scaling and makes it hard to develop anyway. One single person being not that trained on distributed systems may cost a lot of money since such distributed systems are hard to test.


Spring:

You shouldn't see Spring as a full grown application-server. It is more like a simple system to configure things. - At least this is how I see the Spring framework. - Spring provides some out of the box connectors to integrate it in many areas ranging from true application development to web development and JSP.

If you need things to be truly distributed (like agents or what ever), you will need an apropriated underlying application-server, like JBoss or Websphere.

For the co-located systems using a distributed cache (many open source implementations are available) and a distributed/replicated database for distributed transactions. Such systems may easily be configured using Spring. But again you will need an application-server like Tomcat, but the configuration, development, overall performance and maintenance usally succed the distributed solution by some degrees.[/quote]