aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Divya K Konoor <>
Subject Re: Issue with OSGi-JPA entity persistence bundling
Date Wed, 11 Sep 2013 04:15:02 GMT
Hi All,

I have few queries in lines with the discussion below.

How many persistence units are recommended for a product ? Is there any
specific disadvantage of  having many persistence bundles (each with its
own persistence unit defined), such all of them point to the same
database ?

If we follow the model that Christoph has explained below, we will have
more than 10 persistence OSGi bundles such that most of them will have
transitive dependencies on other bundles . Including the dependencies in
the persistence.xml ensures that the relationship /mapping is maintained
and its all working fine but I am not sure if there are any specific
performance overheads or disadvantages having as many persistence bundles
as we need (because in future the bundles might keep growing) and adding
dependencies into each others persistence.xml as discussed


From:	Christoph Gritschenberger <>
Date:	07/01/2013 10:49 AM
Subject:	Re: Issue with OSGi-JPA entity persistence bundling

Hi Divya,

[Moving this to the user-list]

Having PUs in different bundles all accessing the same DataSource works
quite well for us. We (at our company) use a setup similar to [1] for this.

The only pitfall we encountered is with transitive dependencies to
Entities in other bundles.

Example: Entitiy A has a property of Entity-Type B. EntityType C as a
reference To A.
When C is in a different bundle, the persistence.xml of that bundle has
to include the of A and B.

kind regards,


On 2013-06-28 14:25, Divya K Konoor wrote:
> Hi ,
> We are trying to figure out the best possible solution towards the below
> explained OSGI-JPA related problem.
> We use OSGi blueprint specification in WAS Liberty 8.5 version (which
> internally uses Aries) . We use JPA entities for persistence . Our
> requirement is as follows:
> 1. We have multiple JPA entities but all of them cannot be grouped
> in a single persistence bundle as different sets of JPA entities are for
> different functionality/feature and grouping them together would mean
> making them all tightly coupled .
> 2. All communication to the data source has to happen via a single
> persistence unit (PU). This means that all JPA entities should be
> associated with the same PU.
> 3. As per point 1 above, all entity classes cannot be bundled into a
> persistence bundle .The other option is to have one persistence bundle
> JPA entity class or to group JPA entities into persistence bundles based
> the functionality. Either options would mean that there are more than one
> persistence bundles and at least one Persistence Unit needs to be defined
> for each bundle but that might contradict the requirement in point 2
> a) Can more than one persistence unit talk to the same Data
> source/Database ? If this is possible , then each persistence bundle can
> define it's own PU but all of them will talk to the same back-end. Does
> this approach have any undesirable implications ?
> b) If the approach in 3a is feasible , then can a client bundle have a
> handle to more than one entity manager and perform operations using  on
> different JPA entities ? Would this cause any issues ?
> 4. To satisfy requirements 1 and 2 as stated above, we have currently
> resorted to defining one persistence bundle with one Persistence
unit .This
> also carries abstract and super class entity classes. The rest of the
> entity classes are packaged as OSGi fragments with the persistence bundle
> as the host bundle.However, this model runs us into Entity enhancement
> issues as it does not comply with OSGI 4.2 specification section 127
> talks about how OSGi JPA entities cannot be fragments .
> Looking forth to some suggestions and recommendations.
> Thanks
> Divya

View raw message