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).
>
--
st...@hibernate.org
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
