July 2008 AJUG Meeting

I joke that I get two 'get of out of jail free' cards a month for work-related activities. Twice a month I go to user group meetings, one for AJUG, the other for IASA in the evenings. These really are related to work since we do a lot of Java and I've always been involved in Architecture of software systems.

The July meeting of AJUG was about Terracotta, a tool I had heard about, but didn't have a lot of understanding of what it did and how.

The meeting started as usual with Burr Sutter asking about what's new in the community and if anyone had any job openings. Several people described what they were looking to hire and we started a discussion about why it is hard to find good people in Atlanta and about expected salary range of most of the open positions ($85 to $105k was the range thrown around). I relayed a comment a friend at another company made: 'I know the devils here, why would I risk going someplace where I didn't?'. He was referring to the economy and while tech is supposed to be weathering the storm fine, it is a concern for most people. This led to a couple of other comments about losing vacation, negotiating with HR and the reasons why HR wants things cookie cutter for all employees. Very interesting discussion.

Burr then introduced Kunil Bhasin an engineer from Terracotta. Kunil had a good presentation and was willing to take questions from the audience. At first I wasn't sure what Terracotta was, but as he gave more examples and explained how the system works, the more sense it made.

High level: Terracotta provides a file-system backed, in memory 'database' of the name/value pairs available in a network fashion. Very similar to a cache, but with enough differences to not be just considered a cache. At first I was thinking about a JBoss Cache type of solution, but Kunil showed that what was being cached wasn't an object (and thus all the issues with marshalling, changing signatures etc that caches have) but rather a primitive, like a string or integer. So in Terracotta there is an object identifier, an attribute (or class member) name and the current value. Changes in an application are transmitted to the Terracotta server and available for other servers if necessary.

The service is transparent to the application (once you tell Terracotta which objects to manage). So I don't need to do things like checking the cache using a cache specific API, then loading the object via JDBC and putting the object into the cache. Or worse, worrying that the object in the cache is an older version because I'm doing a rolling deployment and the cache server is shared between two apps, one updated, one not.

For the gory details on how this works, go to their website.

Kunil was a very good speaker and handled the crowd very well. I was frustrated though by the crowd. We had a really good turn out, especially for a summer meeting, but it was one of the most argumentative crowds I could remember since Bruce Tate told everyone Ruby solved every problem we've ever had. (Yes, I was one of the ones arguing with Bruce ;-) It seemed that each time Kunil introduced a new concept someone would ask him about performance or why what Terracotta was doing wouldn't work, usually in an offensive tone. He nicely dodged those questions by telling us he'd talk about performance later in the presentation (unfortunately we ran out of time before he could.) He did address a number of questions about locking and concurrency as the questions were asked. It felt like they thought Kunil was attacking their solutions instead of presenting a tool to consider next time. Very strange.

While some of the questions were argumentative, a lot were good, asking details about how they addressed problems people who use caches today encounter. He answered my question about what happens if a new member is added to a class being monitored (Terracotta knows that the old object doesn't need that member so it doesn't try to set it if the member is requested. Having had problems with object caches in this area, this is a nice solution. )

This was also one of the longer sessions we've had a while. Kunil ran out of time and had to blow through several slides about scale and examples of ways to use Terracotta. I think we could have listened to Kunil for another hour, possibly longer if he got into the details of how to use Terracotta with Tomcat for session management (the first thing I thought of when I understood this) or building caches to offload data from the database. Hopefully he or someone from Terracotta will come back, possible for Dev Days (Burr, you listening?)