Tag Archives: Grails

Using H2 with Grails and Tomcat

I’m working on a relatively small application for a some folks without an IT staff. In an effort to simplify the deployment, I’m planning on using H2 as the production database. It will work just fine for five users, and will prevent them from having to install and maintain MySQL or something else.

H2 is the default database in Grails, but you’ll need to make some changes to the production configuration for using a file-based H2 database with Tomcat. Here is the production section of my DataSource.groovy file:

production {
    dataSource {
        dbdir = "${System.properties['catalina.base']}/db/sample"

        dbCreate = "update"
        url = "jdbc:h2:file:${dbdir};MVCC=TRUE;LOCK_TIMEOUT=10000"
        pooled = true
        username = "sa"
        password = "db!admin"

        properties {
            maxActive = -1
            validationQuery="SELECT 1"

Line 3 sets the location and name of the database file. In this case, I’m reading the system property set by Tomcat to determine the location of running instance (catalina.base) and specifying the db will be in a directory called sample in the db directory. You want to create the db directory first. For example, here’s what my Tomcat 7 directory looks like:

On line 5, you’ll want to use update or validate as the dbCreate option so as not to blow away the database each time when you start the application. I prefer update so that Grails can keep simple fast-forward changes in sync.

Finally, on line 6, we build the full datasource URL, substituting in the file location we built above on line 3. I’m setting a password for the database on line 9, but that is optional and really depends on how secure you want the database to be.

Now, when you deploy the WAR file of the Grails application to Tomcat, it will use the embedded H2 database for production, saving the file under the Tomcat location. You can also put the DB file anywhere you want, but my goal was to keep the whole application (Tomcat + Grails) together so I could provide it as a preconfigured Zip file.

The Limits

Erik and I had lunch yesterday with a cool local entrepreneur, Sunny, who has banked his product on Grails. His company also does Grails consulting on the side, so he has several years perspective on using Grails for both his own stuff and for clients.

I was interested in talking with Sunny to discuss the limits of Grails and what had been his experience on things to watch out for. My current Grails project is winding down, and I would like to use it more in the future, so it is always interesting to talk with someone further down the path. Here are some of the nuggets of wisdom he gave us about Grails:

Dynamic Typing

While Sunny appreciates the dynamic nature of Grails, team size can tip it from a benefit to a liability. With more people on the team, he found he was having to write more tests to compensate for an increase in errors from using dynamic typing. Since the compiler can’t pick up all the dumb stuff, a lot of a testing was needed to ensure the correct output. Sunny uses a distributed development team, so not all the developers are sitting in the same room sharing knowledge.

My own guess is that the sweat spot for a Grails team is 3-4 developers working on-site together. As soon as you get too many developers, or they are geographically distributed, the increased productivity of Grails starts to get offset by the extra testing required for simple things that wouldn’t be needed in a statically-typed language. On the plus side, Grails makes it very easy to write tests, but that is still code that needs to be written.

I would imagine this fits in the same sweat spot as Ruby on Rails, so I would be interested to heard from my RoR friends if they see the same issues.


While GORM makes things easy, at it’s roots, it is using Hibernate. That means all the rabbit holes you can go down with Hibernate are just as dangerous in Grails. In Sunny’s case, he has over 100 domain classes in his product, and managing them becomes a chore. The biggest problem is working with deeply nested object hierarchies and cascading updates.

I’ve seen this same issue with straight Hibernate, so it’s not the fault of Grails. One of my prior applications had several eight-to-ten deep persistent object graphs, and it was a total nightmare for doing updates or creating new objects. There was a lot of compensating code around creating the graphs that ended up causing lots of problems when it came time to update an object in the graph. The optimistic locking would get confused and think you were trying to update an outdated version of the master object.

I would apply the same wisdom to Grails as I would to Hibernate: avoid deeply nested domain models.


I haven’t deployed any Grails applications that handle a high user load, and Sunny’s application is more batch-oriented. What he saw is that Grails got extremely slow in batch operations, mostly due to how Hibernate handled transactions.

He recommended turning on SQL tracing for your hotspots to really see what is going on, and tune appropriately. In his case, he had what he believed was a simple operation, but it resulted in over 20 SQL operations at the Hibernate layer.

This is a danger zone for ORM in general. I’ve seen it on about every Hibernate application I’ve dealt with. Hibernate likes to get chatty, and unless you really pay attention, you can end up with issues that drastically impact your performance under load. If you really care about performance, make sure every SQL operation counts.


I haven’t had to deal with this, but Sunny has worked with applications using about every version of Grails. The big pain is upgrading between Grails versions. Outside the language features that change between versions, plugins are one of the biggest problems. He found that the supported “core” plugins tend to play nicely together in upgrades, but he makes use of a lot of third-party plugins. These plugins end up having version conflicts on transitive dependencies that are painful to sort out.

This is another issue that isn’t specific to Grails, and I’ve run in to on about every large Java project. Java has a rich community, with a billion open source libraries to solve about any need. Unfortunately, you can too easily go into “DLL hell” with your jar files when libraries want to include different versions of the various libraries.

My own preference is to try to stick to the core SDK, be it the JDK, Spring or Grails, and really think hard about what you include. My favorite peeve is including Jakarta Commons just to get a cheap toString() method. You now end up with a frivolous dependency that will end up biting you in the butt later.


Sunny has been really happy with Grails, in spite of the limitations. He’s looking forward to some of the new Groovy 2.0 features around static typing to eliminate some of the unit testing needs. And it it sounds like Grails is growing. More startups are starting to use it, and it sounds like it is more popular in Europe than here in the states.

Outside the dynamic typing, most the issues he has seen are endemic to any large Java application. Grails still provides a significant productivity boost over any of the other JVM-based options out there.

The Easy Button

I’m about six weeks in to what has turned out to be a medium-sized project, and I’m hating the thought of my next Java project. Why? Because this project is in Grails and it has been such a joy to work with, it will be downright painful to do a classic Java / Spring MVC application again.

This is my third project using Grails. Each project has given me a chance to dig deeper in to the framework. The first project was more as an observer/reviewer and I wasn’t impressed with the outcome. The second project was me writing the code, and it started to click. Now, on the third project, I’m really starting to appreciate the framework.

So why does Grails rock? Here’s a few of the key things I would have a hard time dealing without.

  1. GORM makes database access infinitely simpler than any of the Java alternatives out there. It is simple to create new domain classes, and also to map to existing databases.
  2. Validation is dirt simple. I’m using a few custom flyweight objects for a tricky page, and by adding a simple @Validateable annotation to the class I can make use of a constraints block on my own class. And it ties in with the error messages.
  3. Thanks to the Grails command line, development is super fast. Make changes and they appear immediately. There is no twiddling your fingers waiting on a Maven build script.
  4. The included taglib is actually pretty comprehensive. I still have a fair bit of custom JQuery code, but even it very cleanly ties in to the Grails controllers for AJAX calls.

My only pain with Grails has been the same one that has vexed Java developers for a decade: the java.util.Date class. This class remains a steaming pile, even wrapped in Groovy goodness. But the solution to this problem is one plugin away. Every sane Grails developer should be using the Joda Time plugin to handle dates.

So Grails is my new shizzle. I plan on using it at the next hackathon, and hopefully will use it for my next project. Any Java developer that hasn’t taken a look at Grails 2.0 really needs to give it a glance and see what they’re missing.

GORM Recipes

As I’ve been diving into Grails, one of the most frustrating parts I’ve had to deal with has been GORM. It is deceptively easy to do the simple stuff with GORM. But as soon as I got to the point of wanting to do aggregate functions, grouping, or other more sophisticated queries, I ran in to wall.

Rather than diving in to SQL, I opted work through the documentation and various blog posts to find the “GORM Way” of doing things. I also documented what I found. The result is this rather extensive article on GitHub called GORM Recipes.

The text was way too large for this blog, so I opted to put it on GitHub. This thread is for feedback and questions about the GitHub article.

Coding in to 2012

Instead of predictions, last year I made a wish list for Santa of things I wanted to have happen in 2011. Looking back at the list, I guess I must have been pretty naughty last year, because the stocking ended up pretty empty. Here was the list, and what I actually got:

  • Google to kick Oracle’s ass over Android: this turned in to a total stalemate, although I could say Google “won” based on the number of Android activations and the butt-kicking Oracle’s stock is getting. I’m actually pretty ambivalent a year later over who wins. I don’t foresee ever buying a Android device, so the whole battle is orthogonal to my interests.
  • Someone to finally build a good Windows notebook: nothing but a lump of coal for me. Lenovo is probably the closest, but none of the PC makers have hit on a Windows 7 equivalent of the Macbook Pro.
  • ActiveState to push out ActiveRuby: another lump of coal. I’m not too disappointed though. I was expecting Ruby to go more mainstream, but instead it had all the thunder sucked out of it by NodeJS. Ruby is becoming the new Java, without the Java part.
  • Google to buy Sencha (ExtJS): more coal. I’ve actually given up on someone buying Sencha. I’m suspecting they have bigger plans than a simple exit. Unfortunately, the market is getting a lot tougher and they may have missed their sweet spot. Sencha Touch is the best tool going in the mobile JavaScript widget space, but it is only a matter of time before JQuery Mobile, Dojo and KendoUI catch up.
  • World Peace: a whole truckload of coal, along with a story that would take more than a few beers to cover.

In spite of a garage full of coal based on my visions of geek sugarplums for last year, I’ll brave speculating on a few things I would like to see happen this year.

  • Grails will get hot: yes, I bashed the crap out of Grails earlier this year when I let my team give it a try on a project. But since then, Grails 2.0 has gone final, and excellent tooling support has arrived in the form of IntelliJ IDEA 11. I’ve been rocking the world doing some Grails work using Bootstrap and KendoUI, and I really appreciate Grails for providing a bit more structure than Rails without having to jump into the rigid world of Java/Spring. I’ll be doing all my personal projects in Grails this year.
  • Kendo UI sneaks in: I originally wrote off Kendo UI as just an attempt by Telerik to clone ExtJS. It shares the same dual licensing model of ExtJS and plays in the same space. In reality, Kendo UI sits somewhere between JQuery UI and ExtJS. Kendo UI provides a good looking library which is easy to implement since it is based on JQuery. While ExtJS is much richer, it is also much harder to work with — there is no such thing as a casual ExtJS developer. Kendo UI also has excellent theming support, and I expect them to evolve it pretty rapidly throughout the year. Kendo UI is what JQuery UI should have been, and this will the framework to watch.
  • NodeJS jumps the shark: NodeJS busted onto the scene this year and got a lot of people very excited about it. Like a new puppy, it was fast, light and a lot of fun to play with. But now that puppy is taking on weight and the peeing on the carpet is starting to get old. Things will only get worse now that NodeJS has sold their souls to Microsoft. I expect NodeJS to enjoy a record short 15 minutes of fame, at the expense of Ruby on Rails.
  • Evil is the new Black: everyone should realize by now that every large technology company is evil. From Facebook and Google stealing your lives to pitch you advertising, to Apple and their walled garden, all these major companies are running with their own evil agendas and we’re just along for the ride. Even Twitter is jumping on the Evil bandwagon. 2012 will be the year you learn to get over it, and there will be good money to be made riding on Darth Vader’s cloak tails. Evil will be the new black.