Clustering with Spring - best practices?

[mad0master]

My first question would be:
- Currently, is there a performance problem?

I guess the answer to this question is "yes".

Then, the following question is "do you know where the bottleneck is?"

Yes and no!
we have arounf 70000 of users with ten time more data to proceed.
So i wonder if it's possible to reduce the load on the system introducing secon webapp server.

[mrpantsuit]

I've spent a couple of weeks making my app "clusterable" w/ Terracotta. My goals are scalability and availability. Here are my initial impressions:

Pros
- Follows IoC paradigm. There is no API, so your code never becomes Terracotta dependent. Clustering is configured declaratively.
- Thread synchronization semantics are honored across the cluster. So, if your Threads are thread-safe, they can be clustered with no code changes (more ore less). Also, this allows powerful techniques for fail over and node death monitoring. I don't know if any other clustering libraries/frameworks with an equivalent feature.
- Integrated support for common problems: Hibernate, EHCACHE, session clustering.
- Error messages are descriptive and helpful, including solution suggestions

Cons
- Your app must be run with a special bootclasspath jar that must be created for the specific JRE you're using. This complicates deployment.
- Hub-and-spoke architecture - you have to run a separate Terracotta (TC) server application to which each cluster node will connect (which itself must be clustered to avoid a single point of failure). This also complicates deployment. Some (Tangersol Coherence guys) claim that this design also entails inherent performance limitations, which Terracotta disputes.
- All shared classes must be instrumented, which has the potential for causing problems in areas unrelated to clustering
- Configuration of locking can be tricky and difficult to debug