Clustering in Spring

Jonas Boner is talking about clustering in spring, a topic of interest since I am currently developing applications that are deployed into a clustered envrionment, and I want the fact thta applications are deployed into a clustered environment to be transparent. It should be possible to deploy applications that are clusterable also in to non clustered environments such as an embedded Jetty container because that facilitates effective unit testing.

Jonas comes up with a problem definition, scaling and that we need to share data throughout multiple JVM's. I think that in most cases, this should not be neccessary. In stateless applications you might just as well keep multiple copies of reference data (which constitutes what Martin Fowler refers to as the knowledege tier), which is most likely read-only anyway.

Jonas starts go into an example, a Store domain class that is subject to crud operations, and how to replicate state changes across a cluster. Hmmmm, this sounds more like how to replicate state across a cluster, well before you do that, ask the question do you need to? If you want to store the data, put it in the database, you will have to put it there eventually anyway.
Now he continues to discuss aspects related to track changes, well, I have been using Hibernate for that some time, so this is for the most just problems from an OR mapping perspective.

Now some stuff that actually relates to the spring clustering stuff and Teracotta of course, which is the product you will need to support directly what Jonas is referring to. Hani has some viewpoints on this.

In my perception try to design your application so that you have uniform access to data, either read mostly/only reference data and operational data. By designing a data layer effectively I see no reason whatsoever to associate spring with clustering throuch teracotta. If clustering relates to sharing data in a cluster, use isolate this in the data layer. You will most probably be using an OR-mapping tool anyway. Seems as Jonas is taking areas related to data synchronization from the data layer and moving it higher up in the application tiers where tehy do not belong. Synchronizing data using the database is probably the most effective solution anyway.