aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan Keane (JIRA)" <>
Subject [jira] Commented: (ARIES-137) Lifecycle issues with PersistenceBundleManager
Date Tue, 02 Feb 2010 10:42:19 GMT


Alan Keane commented on ARIES-137:

I should have clarified that the ExecutorService I was suggesting would actually be a single
thread pool executor .
This in effect would work as an ordered queue of tasks submitted in the order the events are
received. Executing
these tasks (adding/removing both providers and persistence bundles) in order removes a lot
of the synchronization 
problems (such as provider removed before addingBundle completes or while state change is
being processed)

I didn't look closely at MultiBundleTracker but from what I have seen this delegates to an
underlying framework BundleTracker
so the current state / bundles tracked should be available there.

> Lifecycle issues with PersistenceBundleManager
> ----------------------------------------------
>                 Key: ARIES-137
>                 URL:
>             Project: Aries
>          Issue Type: Bug
>          Components: JPA
>            Reporter: Alan Keane
> EntityManagerFactory only gets registered for a unit if a matching PersistenceProvider
> is bound before the persistence bundle is added to the tracker.
> The PersistenceBundleManager will only attempt to setup an EntityManagerFactoryManager

> for the PersistenceProvider services available at the point when a persistence bundle

> is first detected and subsequently only tracks the persistence bundles that get matched
with a Provider.
> Any Persistence bundle added to the tracker before a (suitable) PersistenceProvider is
> available will never get matched with a provider.
> The PersistenceBundleManager#addingProvider method should check for persistence bundles

> that are not matched with a provider and attempt to resolve.
> One possible solution would be that the addingBundle and setUpManager methods use a 
> null object style pattern (or similar) for the EntityManagerFactoryManager so that 
> detected persistence bundles without a matching provider are still tracked. 
> When a provider service is then bound to the PersistenceBundleManager via addingProvider,

> iterate through all tracked persistence bundles and attempt to match those that do 
> not have a valid EntityManagerFactoryManager associated.
> (Note: MultiBundleTracker does not expose the bundles tracked, but by exposing getBundles()
> for above and also using getObject() where the EntityManagerFactoryManager is being returned
> there probably wouldn't be any need for bundleToManagerMap and associated synchronization)
> Also I think an ExecutorService should be used for the setUpManager calls rather 
> than this work being done on a framework event thread.
> (I don't have time right now to look at this properly, so somebody might want to have
> look/take this in the meantime)

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message