Vyas Sanzgiri wrote:I just see one datasource in the configuration file you posted. Can you please post the complete file with 2 data sources and the exception ? It looks as if you are naming both beans entityManagerFactory. Try changing the name
Jagdish Gahlot wrote:hi Christian.. thanks for your help, your example is completely working but i have one situation where i don't want to declare 2 persistence entity factory bean (LocalContainerEntityManagerFactoryBean) rather than i want to use single persistence factory dealing with multiple PUs which in turn will use multiple Datasources. i tried lots of option but couldn't get.
Is there a way that we can declare one single bean of LocalContainerEntityManagerFactoryBean which will be defining 1 PersistenceUnitManager and that PersistenceUnitManager will define a list of datasources. then how my DAO will use these Datasources (either of them at a time) ? also in persistence.xml file i will define 2 persistence unit name bt how there PU name will be linked with datasources defined in my applicationContext.xml 's datasources. i hope everyone is getting what i mean to say exactly.
Each entity manager factory provides entity manager instances that are all configured in the same man
ner (e.g., configured to connect to the same database, use the same initial settings as defined by th
More than one entity manager factory instance may be available simultaneously in the JVM. 
 This may be the case when using multiple databases, since in a typical configuration a single entity manager only communicates
with a single database. There is only one entity manager factory per persistence unit, however.
Jayesh A Lalwani wrote:You can't have one EMF going to 2 PUs. One EMF will always manage 1 PU. You need to create 2 EMFs and inject the PU that you want to use into your DAO class.
I have a similar problem where I need to be able to connect to multiple databases from the same application. A thread will always connect to one database. All databases are identical. Each client has it's own schema, and at runtime, I need to connect to the correct database.
What I ended up doing is I extended HibernatePersistenceProvider. This extended provider contains a map of HibernatePersistenceProvider; one for each client. I have a thread local variable that contains the name of the client. This is set before any DAO calls are made. My Extended Persistence Provider checks the thread local variable and delegates all calls to the correct real HibernatePersistenceProvider. I used the same pattern with DataSource too. I extended DataSource to contain a map of other DataSource; one for each client. In both cases, if my extended class sees a new client, it creates a PersistenceProvider/DataSource for that client and puts it in the map (note thread safety important here )
So, I have only one PU that uses my extended persistence provider. I configured EMF to use this PU. I provide the extended datasource to the EMF. This EM is injected into my DAO classes. At run time, the service that recieves the request, sets the thread local variable and calls the DAO. DAO calls EM, EM calls the Persistence Provider. Persistence Provider routes all the calls to the "real" Persistence Provider. Internally the real persistence provider calls my extended data source, which uses the same thread local variable to route the calls to the real data source.
And when my army is complete, I will rule the world! But, for now, I'm going to be happy with this tiny ad:
Sauce Labs - World's Largest Continuous Testing Cloud for Websites and Mobile Appshttps://coderanch.com/t/722574/Sauce-Labs-World-Largest-Continuous