aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothy Ward (JIRA)" <j...@apache.org>
Subject [jira] Commented: (ARIES-137) Lifecycle issues with PersistenceBundleManager
Date Tue, 02 Feb 2010 09:54:19 GMT

    [ 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.


Mime
View raw message