[hibernate-dev] Concept of "service availability"

[Scott Marlow]

On 08/20/2012 11:19 PM, Steve Ebersole wrote:
> This ties together a few different discussions that have been going on
> simultaneously on the mailing list that I think are all related.
>
> Right now to configure certain services (select one impl over another)
> users generally give the FQN for that impl Class.  For example to use
> C3P0 connection pooling users would say:
>
> hibernate.connection.provider_class =
> org.hibernate.service.jdbc.connections.internal.C3P0ConnectionProvider
>
> We have discussed why this is bad even before any of the OSGi
> discussions and the solution we wanted to shoot for was that of naming
> "selectors" such that the user would instead say:
>
> hibernate.connection.provider_class = c3p0
>
> And "c3p0" here would be interpreted to mean "instantiate and configure
> the
> org.hibernate.service.jdbc.connections.internal.C3P0ConnectionProvider
> Class".  But that still means a limited set of short name values *and*
> still gives us a problem (iiuc) under OSGi due to visibility.
>
> So what I propose instead is a way for service implementors to be
> registered under a short name via discovery.  The main piece to this is
> the "registry" (which is also a service under the BootstrapServiceRegistry):
>
> interface AvailableServiceRegistry extends Service {
>       public <T> Class<? extends T>
> findAvailableServiceImplementor(Class<T> serviceRole, String selector);
> }
>
> class AvailableServiceRegistryImpl
>           implements AvailableServiceRegistry,
>           ServiceRegistryAwareService {
>       private Map<Class,Map<String,Class>> availableImplementors = ...;
>
>       @Override
>       public <T> Class<? extends T>
> findAvailableServiceImplementor(Class<T> serviceRole, String selector) {
>           // purposely simplistic :)
>           return availableImplementors.get( serviceRole ).get( selector );
>       }
>
>       @Override
>       public void injectServices(ServiceRegistryImplementor
> serviceRegistry) {
>           final LinkedHashSet<ServiceAvailabililtyNotifier> notifiers =
> serviceRegistry.getService( ClassLoaderService.class ).loadJavaServices(
> ServiceAvailabililtyNotifier.class );
>           for ( ServiceAvailabililtyNotifier notifier : notifiers ) {
>               for ( ServiceAvailabililty availability :
> notifier.getAvailabilities() ) {
>                   // again, purposely simplistic
>                   Map<String,Class> serviceImplementors =
> availableImplementors.get( availability.getRole() );
>                   serviceImplementors.put(
>                           availability.getSelector(),
>                           availability.getImplementor()
>                   );
>               }
>           }
>       }
> }
>
>
>
> Outstanding question... Especially in OSGi, where service bundles can be
> added/removed, how do we best account for cleaning up no-longer valid
> references (even more importantly perhaps, what the hell does it mean to
> Hibernate when a ConnectionProvider implementation, for example, that is
> in use gets taken away?!?).  Perhaps this is just where an OSGi-specific
> Hibernate ServiceRegistry implementation would come into play.
>

Adding Jesper as we were talking about how to handle "quiescence 
shutdown" at the AS level, which sounds related.  Once we take the 
ConnectionProvider away, I would expect the Hibernate session(s)/session 
factory to be broken.  If/when the ConnectionProvider comes back, 
Hibernate would need to re-establish it.  I'm thinking that we need a 
neutral (autonomic) API/SPI for attempting to re-establish the 
ConnectionProvider.

For the most part, a "quiescence shutdown" of the AS, would mean keeping 
the ConnetionProvider alive until the end (of the planned shutdown). 
I'm thinking that being able to re-establish the ConnectionProvider 
would still be useful (for AS "quiescence shutdown"), especially if 
something goes wrong during the shutdown and manual intervention is needed.

To me, the process of re-establishing the ConnectionProvider, could be 
labeled "self healing" (with the help of an autonomic API/SPI).