When you deploy an application using eclipse or ant, Resin propagates the .war updates to the cluster using the triad as the reliable store. The deployment is both incremental and transactional. Only changed files need to be sent, and the updates are only visible when they are complete and visible. Partial or incomplete deployment does not update the site.

1. eclipse/ant sends the .war to triad server A
2. Triad server A replicates the .war to triad servers B and C
3. The triad updates the rest of the cluster with the new .war file
4. Once all servers have the new version complete and verified, they can restart the web-app with the new data

(more…)

With Resin 4.0, we can expose our distributed caching/store capabilities to all developers, using the javax.cache interface. Internally, our distributed cache builds on 10 years of work with distributed sessions. So the jcache support isn’t a new capability, really, it’s just newly available for developers.

As an introduction, I want to show the prototypical code sample (it’s an injected Map), and the configuration (one XML tag in the resin-web.xml). The configuration is simple because Resin’s clustered cache is designed for Resin and automatically inherits the cluster and triad configuration from the Resin deployment.

Distributed caching reduces load on the database, improves latency, and can improve reliability by providing a failover capability in a load-balancing configuration. Essentially, you store serialized objects in a Map and the cache makes the Map entries visible across the entire cluster pod automatically.

(more…)