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

Ok, going to start working this up on master tomorrow. We will just tackle the "going away" problem if/when it actually arises. On Tue 21 Aug 2012 05:55:31 PM CDT, Steve Ebersole wrote: > 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 -- steve(a)hibernate.org http://hibernate.org