How to specify different amount of persistence units in JPA persistence.xml at a deployment level

I have a J2SE program that I'm moving over to use JPA. The existing program talks to anywhere from 1 to 4 databases. The database it talks to is dependent on a deployment-specific mapping of table -> database. When more than 1 database is used, it is because some tables have been shifted to another database (horizontal sharding on a database level, not table level). This is configured on a per-deployment basis - it's up to the user to decide how they wish to structure their database setup.

Existing code looks like

Connection con = getConnectionBasedOnTable(domainObject.getClass());
// execute statement, etc...

With (J2SE) JPA I wish to use something like:

EntityManager em = getEntityManagerBasedOnTable(domainObject.getClass());
// persist, etc...

The reason for the indirection is because different users have different requirements. A small user may only have a tiny database, so a single server is enough. A large organisation may have huge databases, so we address this by placing high performance tables on high performance servers, and so on. Also used by some users to keep sensitive data in a (costly) high security environment while keeping non-sensitive data in a (cheap) medium security environment. So there's no one size fits all database approach. Hence indirection. Also note that the tables that are eligible for separation don't have any foreign key constraint issues.

Now that I'm trying to move to JPA, how can I allow end users to define their database structure? Is there a way to programmatically configure persistence units? Including defining new persistence units not specified in persistence.x开发者_如何学Goml? How can I achieve my goal?

I can think of the following:

• Predefine 100 or so persistence units in persistence.xml: "db1", "db2", etc... and have the program read in an external configuration file which applies properties to them (Persistence.createEntityManagerFactory(name, properties)). Ugly, limiting.
• Move to a non-JPA solution (I really wish to avoid this. We want to use JPA because of its standards based nature).
• Deploy user-specific JARs, or build scripts that can edit/modify the JAR's persistence.xml to use their setup. A bit of a hack for sure.

For what it's worth, we are using Hibernate's JPA implementation. I have searched for a way to configure Hibernate's JPA and haven't had any success.

---

I'm closing this question because no suitable answer. For those that are interested, I ended up opting for predefining all possible combinations of persistence units in the XML file.

Edit: It's now 2013 and I needed to revisit this problem, and turns out it is possible to do this. See Is persistence.xml requied when working with Spring and Hibernate? - you don't need to use Spring, but the general point of using HibernatePersistence.createContainerEntityManagerFactory() is the key.

---

Not sure it'll help you, but you can try to see if Teiid solves your problem. This way, you can aggregate all data sources into a single point (Teiid), making it transparent to your app where the data come from.