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

Not so concerned about shutdown situations. More, imagine a custom ConnectionProvider implementation provided by user. And the use case of upgrading that implementation "in flight". I think thats the OSGi use case. And not so sure Hibernate should be implementing this self healing. I guess it depends how deeply we want to support the OSGi model above and beyond JSE/JEE Obviously a used ConnectionProvider just going away is going to render the SessionFactory using it broken. On Tue 21 Aug 2012 08:22:11 AM CDT, Scott Marlow wrote: > 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). > -- steve(a)hibernate.org http://hibernate.org