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