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).
>>>
>>
>> --
>> st...@hibernate.org
>> http://hibernate.org
>
> --
> 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
