JPA/EclipseLink multitenancy screencast

I find JPA and in particular EclipseLink 2.3 to be particularly well suited to illustrate the concept of multitenancy, one of the key PaaS features en route for Java EE 7.

Here’s a short (5-minute) screencast showing GlassFish 3.1.1 (due out real soon now) and its EclipseLink 2.3 JPA provider showing multitenancy in action. In short, it adds EclipseLink annotations to a JPA entity and deploys two identical applications with different tenant-id properties defined in the persistence.xml descriptor. Each application only sees its own data, yet everything is stored in the same table which was augmented with a discriminator column.

For more advanced (or more realistic) uses such as tenant property being set on the @PersistenceContext, XML configuration of multitenant JPA entities, and more check out the nicely written wiki page.

Author: alexismp

Google Developer Relations in Paris.

8 thoughts on “JPA/EclipseLink multitenancy screencast”

  1. Thanks Alexis – nice introduction.
    One thing that occurs to me is that it would be hard to keep both apps in sync if any schema changes occur, but if the business is aware of that it can’t be too hard to manage.
    N00b question: In order to get this working, do I just need EclipseLink 2.3 JPA jar(s)? Or do I need a specific implementation of EclipseLink 2.3 JPA? Can other JEE servers even support it?

  2. You should just need EclipseLink 2.3 and you can use this functionality in JavaSE or any container that supports JPA 1.0 or 2.0.

  3. Yasser,
    EclipseLink does have partitioning support for using tables across different schemas/db. On the @Multitenant front we are starting on additional strategies such as TABLE_PER_TENANT.

  4. Why are you cloning the application? Isn’t multi-tenancy all about using one instance of an application with multiple tentants. I understand that you can have some tenant-specific customization that way. My question is, how does EclipseLink support the scenario where you have one instance of an application with a huge number of tenants? Do you need @Multitenant annotation at all? Would it suffice just to add an extra tenant-id column and include the tenant-id in all queries? And how does @Unique behave in a multi-tenant environment? I would expect that it enforces uniqueness within a single tenant.

  5. This is not a classic Multitenancy app scenario is it? While I understand that it is just a proof of concept, duplicating project might not be the common scenario (think 10 BUs). Also having to rollout updates to the project 10 times might not be ideal. Having tenancy id discriminator being part of the User’s Session Context (REALM) might be a more apt way of implementing it.
    But the DISCRIMNATOR column annotation on the DB side is perfect.

  6. Yes, this is a simplistic example of multitenancy.
    A more realistic one would be to set the tenant-id at injection time (@PersistenceContext).
    Mutitenancy is pretty much cross-cutting all the platfoem APIs and I would hope that once Java EE 7 is done, the use-cases are easily usable and are hiding away most or all the details.

Comments are closed.