First8 staat voor vakmanschap. Al onze collega’s zijn een groot aanhanger van Open Source en in het bijzonder het Java-platform. Wij zijn gespecialiseerd in het pragmatisch ontwikkelen van bedrijfskritische Java toepassingen waarbij integratie van systemen, hoge eisen aan beveiliging en veel transacties een belangrijke rol spelen. Op deze pagina vind je onze blogs.

Grails multi tenant databases – update for 3.2

Multi-tenant Grails revisited: update to Grails 3.2

Before reading any of this, please know that a full article was published recently about multi tenancy with Grails 3.1.

The key of multi tenancy is that the data handled should ‘stick‘ to a certain tenant, primarily used for white label product situations, or storage divided by region because of its size.

One of the problems there though, was that GORM did not play nice with having multiple data sources. Well, things have changed!

With the release of GORM 6, that integrates nicely with Grails 3.2.x, Grails now has excellent support for multi tenancy. This is largely because of the support by the underlying ORM framework Hibernate which was updated to major version 5.

gorm: blue or bluey-grey (Cairngorms ‘blue stones’)
Gorm: blue or bluey-grey (Cairngorms ‘blue stones’)

Some things remain the same

For groovy Sql support, you will still need to create your own switching data source as before. The previous article covers that as well. There’s just a nice little trick that makes configuration a little less error prone.

The following code just takes whatever data sources that have been configured, logs what it finds, and wires them up to a switching data source.

Setting up Grails with GORM 6

To work with GORM 6, the project dependencies need to be setup properly using Gradle.


Configuring GORM for multiple databases

We configure application.yml for GORM multi tenancy, switching on databases in our case.

We provide our own implementation, much like the switching data source that was previously used for groovy Sql.

The customer resolver (note that are a few simple ones ready to use in the ‘web’ component)

One big catch

Though the default data source bean is named ‘dataSource’, the tenantId should be ‘DEFAULT’. This is not at all obvious from reading the documentation (or grails sources for that matter). You may have noticed the trickery in the code examples earlier. Our customer resolved will return ‘DEFAULT’, from the thread local, when the default data source named ‘dataSource’ should be selected.

For others it’s just the name that was defined in the data sources config. For instance, a data source named ‘foo’ produces a bean named ‘dataSource_foo’ and the tenantId will be ‘foo’.


All is well

With Grails 3.2, multi tenancy is again fully supported like it was with Grails 2.x. It’s great to see that the framework is flexible enough, building on powerful open source projects, to provide all the features that even the most complex cases require.





Stay tuned for in depth solutions like: having a trigger-driven primary key with Oracle 12 and still have Hibernate/GORM understand identity.