Re: [hibernate-dev] Concept of "service availability"

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