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

Everyone else ok with this idea? On Tue 21 Aug 2012 08:27:25 AM CDT, Steve Ebersole wrote: > 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 -- steve(a)hibernate.org http://hibernate.org