aries-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Edelson <>
Subject Re: AW: JPA Service: EntityManagerFactoryBuilder
Date Tue, 28 Sep 2010 16:25:04 GMT
On 9/28/10 11:17 AM, Timothy Ward wrote:
> 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.
Nor does it say it can't. If a method is really only meant to be invoked
once, that would warrant specific mention.

> 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 :)
The Rebinding section (127.5.4) pertains to EntityManagerFactory
services registered by the JPA provider. It does not apply to
EntityManagerFactoryBuilder instances nor does it appear to apply to
EntityManagerFactory instances created by EntityManagerFactoryBuilder.

I think this would be a better discussion for osgi-dev.


> Regards,
> Tim
> ----------------------------------------
>> Date: Tue, 28 Sep 2010 10:40:37 -0400
>> Subject: Re: AW: JPA Service: EntityManagerFactoryBuilder
>> From:
>> To:
>> 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
>>> 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?
>>> 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:
>>>> To:
>>>> 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

View raw message