messingblog

Terracotta is one of these really cool frameworks that can make Java applications run on a computer grid without any or minor modification to application code. And even better, it comes with a dual-license, one commercial, and the other a full featured community version.

Something Good Can Always Get Even Better

The people at Terracotta are steadily improving their product. This means, at some point you will find yourself thinking about upgrading to a new Terracotta version.

Terracotta’s website states:

Overall, the upgrade from a previous release of Terracotta to 3.0 should be a seamless process.

So let’s find out, how seamless such an upgrade actually is. When you really have the need for clustering, your application will already come with a certain amount of complexity, so upgrading has its issues anyway. In the following, I share my considerations about how to upgrade from Terracotta 2.x to 3.x. Most of it may also apply to any other major Terracotta upgrade.

Upgrading the Database Schema

Terracotta uses a database. Surprised? Okay, it is not the database you usually think of, but when you decide to make your clustered data persistent, Terracotta stores all your clustered objects in a database. I absolutely recommend to make your clustered data persistent. It ensures that your data is always available, even after the worst crash scenarios (okay, burning down your data center might not be covered, though). In 3.0, Terracotta changed the database schema. Assume they had good reason to do so! As a consequence, you have to migrate your persistent cluster data when upgrading.

Now I hear you saying: Uff! Don’t you?

Okay, here are some ideas to deal with it:

1. You already have a migration strategy in case your data model changes, and you should have.
2. You store all persistent data in a database anyway, so throw away the old Terracotta persistence store and refill it with the data from your database, be it pre installation or lazily during run-time. Keep in mind that application state data not stored in your database (where it shouldn’t be anyway, that’s the idea of using Terracotta), is lost then.
3. Complain.

Personally, I eagerly opt for #1. As I mentioned before, when you need Terracotta, your application is fairly complex. In that case, besides using Terracotta or not, you always should have a persistent data migration strategy. And do not even dare thinking about #3 as a serious approach.

Upgrading Terracotta Integration Modules (TIMs)

Before we dive into details, just a quick primer on where to store your TIMs. This is just best practice and therefore to be considered as a recommendation.

There are two locations to store TIMs. In Terracotta’s own module directory, or in an optional directory that is specified in the Terracotta configuration file. The latter, of course, should be outside the Terracotta installation directory. Tip of the day: use both.

Store all the modules you will need with a Terracotta installation, such as map-evictors, Terracotta’s own concurrent string hash map implementation and so forth, inside of Terracotta. A general rule of thumb is, what can be downloaded with the tim-get tool should find its way into Terracotta’s module directory. Whenever you update Terracotta, everything TIM in there needs to be updated as well.

Store TIMs that do not need to be changed when upgrading Teracotta, for example, Lucene integration, in your custom module directory. This way, you can safely upgrade Terracotta without to re-install your own TIMs.

To avoid some pain when upgrading, I urge you to follow these steps:

1. It is absolutely mandatory to visit Terracotta’s website before upgrading. Usually, they have plenty information of what has changed from one release to the next.
2. A good starting point is to find which TIMs are obsolete, which ones you need additionally. On major version upgrades, Terracotta might move functionality out of Terracotta into TIMs and vice versa.
3. Then use tim-get to get the TIMs, don’t do this manually. tim-get resolves all dependencies for you and cares about the right module versions.
4. Update your module references in your Terracotta configuration file accordingly.
5. Don’t forget to make the TIMs in the Terracotta module directory available in the classpath of your Terracotta client application.

Session Support Outsourced

Another decision in Terracotta 3.x was to move the session support for web application servers out of Terracotta into TIMs. This makes sense, as there are stand-alone Terracotta applications that do not need session support at all. Furthermore, as there are many different application servers out there, providing support as TIMs rather than out of the box is fairly logical. Whenever a new application server hits the market or an existing comes in its latest flavor, provide a TIM and tim-get it into your modules directory. No update for Terracotta needed.

Conclusion

That’s it. Not too simple, but fairly seamless. The only big thing is upgrading the Terracotta persistent store to the new version. But this is not a Terracotta upgrade issue, it is a general issue of your application design. You should always think of a data model migration strategy early in your project. Sooner than later you might find yourself rethinking your data model, and at that point you have to do a data model migration anyway.

Many of the Terracotta engineers are avid followers on twitter. When I ran in (self-made) problems with upgrading, I posted there. Immediately I got help. And within in minutes, they updated their downloads page and provided an additional note for migrators.

www.terracotta.org

Tags: cloud computing, grid, Java, Terracotta

This entry was posted on Tuesday, May 12th, 2009 at 8:37 pm and is filed under Terracotta. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.