You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by "Alan Keane (JIRA)" <ji...@apache.org> on 2010/02/02 01:50:18 UTC
[jira] Created: (ARIES-137) Lifecycle issues with
PersistenceBundleManager
Lifecycle issues with PersistenceBundleManager
----------------------------------------------
Key: ARIES-137
URL: https://issues.apache.org/jira/browse/ARIES-137
Project: Aries
Issue Type: Bug
Components: JPA
Reporter: Alan Keane
EntityManagerFactory only gets registered for a unit if a matching PersistenceProvider service
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 a
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.
[jira] Resolved: (ARIES-137) Lifecycle issues with
PersistenceBundleManager
Posted by "Timothy Ward (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ARIES-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Timothy Ward resolved ARIES-137.
--------------------------------
Resolution: Fixed
I have updated the PersistenceBundleManager to track managers with no persistence provider, and to attempt to assign them as providers become available
> Lifecycle issues with PersistenceBundleManager
> ----------------------------------------------
>
> Key: ARIES-137
> URL: https://issues.apache.org/jira/browse/ARIES-137
> Project: Aries
> Issue Type: Bug
> Components: JPA
> Reporter: Alan Keane
> Assignee: Timothy Ward
>
> EntityManagerFactory only gets registered for a unit if a matching PersistenceProvider service
> 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 a
> 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.
[jira] Updated: (ARIES-137) Lifecycle issues with
PersistenceBundleManager
Posted by "Jeremy Hughes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ARIES-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeremy Hughes updated ARIES-137:
--------------------------------
Fix Version/s: 0.1
> Lifecycle issues with PersistenceBundleManager
> ----------------------------------------------
>
> Key: ARIES-137
> URL: https://issues.apache.org/jira/browse/ARIES-137
> Project: Aries
> Issue Type: Bug
> Components: JPA
> Reporter: Alan Keane
> Assignee: Timothy Ward
> Fix For: 0.1
>
>
> EntityManagerFactory only gets registered for a unit if a matching PersistenceProvider service
> 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 a
> 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.
[jira] Commented: (ARIES-137) Lifecycle issues with
PersistenceBundleManager
Posted by "Timothy Ward (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ARIES-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12828567#action_12828567 ]
Timothy Ward commented on ARIES-137:
------------------------------------
The lifecycle issues in this area are somewhat complicated, and as you suggest, I'm sure there are improvements on the current design.
There are two main issues associated with the Persistence bundle manager:
1) Persistence bundle lifecycle
Any call into the EntityManagerFactoryManager may be re-entrant, as it is possible that the side effects of the persistence bundle state change will cause it to change state again. However, we should not be synchronizing when using the PersistenceProvider service or when registering the EntityManagerFactory in the service registry. To add further complexity, each EntityManagerFactory should only be created once (until it is closed).
2) Persistence provider lifecyle
Any update to the list of accessible persistence providers needs to be thread safe, and ensure that any EntityManagerFactory services are unregsistered synchronously by that thread. We also need to eliminate the race condition where a new persistence bundle becomes available simultaneously with the persistence provider being added or removed. As only one of these calls comes through the bundle tracker, and the bundle tracker holds no locks, we cannot guarantee any call to getObject() will return the correct value.
To answer the points raised by this JIRA
a) The PersistenceBundleManager#addingProvider method should check for persistence bundles that are not matched with a provider and attempt to resolve.
Yes, it should. I had plans to do this when I started, but not the time to implement them. I could start on this once I've finished some of the logging tidy up and itests.
b) 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
I did not write the MultiBundleTracker, but I imagine that it is somewhat difficult to get an atomic snapshot of the bundles and objects tracked without completely re-writing BundleTracker. In any event, the real problem here is a race condition between a thread removing a provider and a thread creating an EntityManagerFactoryManager. Until some point after the addingBundle call has completed there will be no object returned by getObject(), this means that when the provider is removed we can't get an atomic view of the bundles that might be using that provider unless we keep that view ourselves. It would be nice if the Tracker could be used, but I can't see any way to make the threading work.
c) Also I think an ExecutorService should be used for the setUpManager calls rather than this work being done on a framework event thread.
Is it possible to do this safely when the provider may disappear at any time? It may make more sense if we create the manager first, then assign a provider. Another big issue here is really that we need to make calls out to the ManagedPersistenceUnitInfoFactory, allowing plug-ins to customize the bundle in some way (for example by adding a fragment). This could be worth looking at in the future if we can avoid breaking anything.
> Lifecycle issues with PersistenceBundleManager
> ----------------------------------------------
>
> Key: ARIES-137
> URL: https://issues.apache.org/jira/browse/ARIES-137
> Project: Aries
> Issue Type: Bug
> Components: JPA
> Reporter: Alan Keane
>
> EntityManagerFactory only gets registered for a unit if a matching PersistenceProvider service
> 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 a
> 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.
[jira] Commented: (ARIES-137) Lifecycle issues with
PersistenceBundleManager
Posted by "Alan Keane (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ARIES-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12828589#action_12828589 ]
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: https://issues.apache.org/jira/browse/ARIES-137
> Project: Aries
> Issue Type: Bug
> Components: JPA
> Reporter: Alan Keane
>
> EntityManagerFactory only gets registered for a unit if a matching PersistenceProvider service
> 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 a
> 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.
[jira] Assigned: (ARIES-137) Lifecycle issues with
PersistenceBundleManager
Posted by "Timothy Ward (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ARIES-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Timothy Ward reassigned ARIES-137:
----------------------------------
Assignee: Timothy Ward
> Lifecycle issues with PersistenceBundleManager
> ----------------------------------------------
>
> Key: ARIES-137
> URL: https://issues.apache.org/jira/browse/ARIES-137
> Project: Aries
> Issue Type: Bug
> Components: JPA
> Reporter: Alan Keane
> Assignee: Timothy Ward
>
> EntityManagerFactory only gets registered for a unit if a matching PersistenceProvider service
> 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 a
> 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.