Actually, the two argument call allows you to override the xml configuration, and any defaulting, when creating an EntityManagerFactory. It doesn't say that the method may be called multiple times with different configurations.
Also, you really can't create more than one overriden EntityManagerFactory from the EntityManagerFactoryBuilder. Read the JPA service specification section on rebinding if you don't believe me :) Regards, Tim ---------------------------------------- > Date: Tue, 28 Sep 2010 10:40:37 -0400 > Subject: Re: AW: JPA Service: EntityManagerFactoryBuilder > From: [email protected] > To: [email protected] > > On Tue, Sep 28, 2010 at 5:03 AM, Timothy Ward wrote: >> >> Hi Harald, >> >> The Java SE scenario you describe below is also not guaranteed to work. In >> Java SE many >> JPA providers use the persistence unit name as a unique identifier for the >> persistence unit >> and cache the return value. It really is expected that you have exactly one >> EntityManagerFactory (and therefore database connection) per persistence >> unit. > This defeats the purpose of the two-argument version of > createEntityManagerFactory. Ignoring the map of parameters (assuming > that map contains valid parameters) is a spec violation: > > "When any of these properties are specified in the Map > parameter, their values override the values of the corresponding > elements in the persistence.xml > file for the named persistence unit. They also override any defaults > that the provider might have applied." > > Harald's need seems relatively straightforward. He needs to create a > unique EntityManagerFactory per database. This is foreseen by the OSGi > Enterprise spec and is *exactly* the use case for > EntityManagerFactoryBuilder. See page 408/409, section 127.3.4. The > spec reads: > > "This can for example be used to provide > the database selection properties when the Persistence Unit is > incomplete or if the database > selection needs to be overridden." > > It is correct that the data source of an already created > EntityManagerFactory cannot be changed, but that's what the > two-argument version of Persistence.createEntityManagerFactory and > EntityManagerFactoryBuilder are for. > > Justin > >> >> I'm a little confused as to the use case for this business intelligence >> application. These new >> databases are being added dynamically at runtime, but use the same table >> structure? This >> sounds, to me, as though your application needs to cope with these dynamic >> changes. >> Perhaps if you stop your persistence bundle, re-bind the DataSource services >> to point at the >> correct database, then bring the persistence bundle back up? >> >> Regards, >> >> Tim >> >> ---------------------------------------- >>> From: [email protected] >>> To: [email protected] >>> Date: Mon, 27 Sep 2010 13:57:19 +0200 >>> Subject: AW: JPA Service: EntityManagerFactoryBuilder >>> >>> Hi Tim, >>> >>> it seems I misinterpreted the EntityManagerFactoryBuilder - thanks for >>> pointing this out. >>> >>> But I still don't see how to solve the situation with one persistence unit >>> working on multiple databases with the same structure, neither in OSGi nor >>> in Java EE. >>> >>> In Java SE, I would simply call >>> Persistence.createEntityManagerFactory(puName, props) multiple times, with >>> the same persistence unit name, but different property sets, specifying >>> different datasources. >>> >>> E.g. think of a business intelligence application doing analysis on >>> customer databases, where there is a separate database for each country. >>> Each analysis request refers to given country, and the application has to >>> select the appropriate database at run-time. New countries may be added at >>> any time, so it would not work to hard-code n persistence units and/or EMFs >>> up front. >>> >>> Best regards, >>> Harald >>> >>
