views:

186

answers:

1

So apparently we have the need to create persistence units on the fly. Basically we have this web service and a bunch of identical schemas with identical domain classes. We want to be able to pass a query to the web service where the context path matches a schema. The first time that the service is queried then pass in that schema name and create the persistence unit on the fly and then using it every time thereafter and repeating the process every time a request is made of the service for a schema that has not yet been created.

Is this possible using Spring and JPA given all the building that has to be done at start up for normal PU creation? Is this brilliant idea scalable?

+1  A: 

So if your database schemas are predefined I do not quite get why you would want to create persistence units "on the fly".

The only example - and quite contrived one, at that - I can think of where that may make sense is if the number of schemas is rather large and you do not expect all of them to be necessary during your service lifetime. Even then, all you save is some memory.

So, unless I'm missing something here (and if I am, please clarify what is it you're looking to achieve by creating persistence units "on the fly"), I would suggest you pre-define all your persistence units. You can then create or inject appropriate EntityManagerFactory instances by specifying persistence unit name as parameter.

ChssPly76
Not my brilliant idea but apparently we do not want to write up all the necessary PUs in the persistence.xml file but I'm trying to convince that we need to just write up the PUs in the xml file and then write up additional EntityManagerFactoryBeans. So when a new client is added a new schema is created and then our audit webservice is used to query the temporal tables are goin to be read-only, immutable domain objects. So I think we should use L2 cache -- how do u find integrating Memcached with Hibernate?
non sequitor
It's perfectly understandable to not want to replicate all that code in persistence.xml but nothing prevents you from doing a little XSLT magic. The point is it's a LOT easier to do it during build time than during runtime. As far as memcached goes, I've never deployed it in production (have been using ehcache and jboss cache for clusters) but it has a (third-party) provider for Hibernate (http://code.google.com/p/hibernate-memcached/); no reason why it shouldn't work.
ChssPly76
Also if I add a new schema is there anyway to load the new PUs as they are incrementally added without restarting the server? I think this is the major concern, not having to pull down the server to add a new PU so the client can query the tables.
non sequitor
Ah... that would be rather problematic. With raw Hibernate you can build a brand new sessionFactory and substitute existing one for it. For JPA you're looking at writing your own `PersistenceProvider` to do that.
ChssPly76