[hibernate-dev] Concept of "service availability"

Scott Marlow smarlow at redhat.com
Tue Aug 21 09:22:11 EDT 2012

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 

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

More information about the hibernate-dev mailing list