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

Would be nice to consolidate the notions of "ServiceAvailabililtyNotifier" and "ServiceContributor" (that I just added on metamodel). Such that a ServiceContributor would be able to regsiter the short names as well. On Thu 23 Aug 2012 03:58:10 PM CDT, Steve Ebersole wrote: > 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 -- steve(a)hibernate.org http://hibernate.org