JPA dynamic persistence unit name

Question

I need a way to dynamically specify the persistence unit in a EJB.

Simplified example:

I have an application using multiple databases as data stores. Each of the data stores are structurally the same. Depending on the client connecting to the application I need to access the data from a specific data store.

Therefore, I would like to use the same EJB so that the business logic is not duplicated, but then just select the correct persistence unit based on the client.

Up to this point I've only directly injected the entity manager with the persistence unit name hard coded. Is there a way I can dynamically inject the entity manager with the required persistence unit attached to the EJB? Also, can persistence units be added dynamically during runtime? I currently have to specify the persistence unit in the persistence.xml file. Ideally I would like to create pools on the server jdbc/db1, jdbc/db2 etc as required while the system is running. Then just add these to the central client database and link it to a client, so that when the client connects, it will check the name of the pool, and use it when calling the EJB to get the persistence unit.

I'm still really new to Java EE development. Any help would be greatly appreciated.

Answer 1

In the current JPA version, it's unfortunately not possible to create persistence units dynamically. If this functionality it's important for you, you could consider creating a JIRA issue for it at the JPA issue tracker: http://java.net/jira/browse/JPA_SPEC

Using the @PersistenceContext annotation, it's also not possible to dynamically select a specific persistence unit. This is actually the domain of sharding, which Hibernate once tried to address but then suddenly discontinued. See http://www.hibernate.org/subprojects/shards.html

There are however a few thing you could do to get a similar effect.

One approach is to create a Stateless EJB/CDI factory bean, that you inject with all your entity managers. The cost of this is marginal, since those beans will be pooled and entity managers are not that expensive to be created in the first place.

If you also want to inject them based on some condition, then this condition will have to be available from the context or has to be specified at the injection point (but if you would do that, you could just as well inject the right entity manager directly).

A kickoff example:

@Stateless
@TransactionAttribute(SUPPORTS)
public class ShardingEntityManagerFactory {

    @Resource
    private SessionContext sessionContext;

    @PersistenceContext(unitName = "pu1")
    private EntityManager entityManager1;

    @PersistenceContext(unitName = "pu2")
    private EntityManager entityManager2;

    @Produces @TransactionScoped @ShardedPersistenceContext
    public EntityManager getEntityManager() {
        if (sessionContext.isCallerInRole("FOO")) {
            return entityManager1;
        } else {
            return entityManager2;
        }
    }
}

And then in your beans:

@Stateless
public class SomeBean {

    @Inject @ShardedPersistenceContext
    private EntityManager entityManager;

    // ...
}

Note that you would need Seam Persistence here for the @TransactionScoped annotation. It also might be easier, but a little more verbose, to forget about injecting the entity manager transparently and inject the ShardingEntityManagerFactory instead and obtain the right one from it manually.

Answer 2

This probably is of no help to solve the problem, but you may like to know that this kind of problems is being discussed for the implementation of JPA 2.1

This sounds like one of those cases of multitenancy:

Proposal for Multitenancy Support in JPA 2.1 JSR-338