[hibernate-dev] Concept of "service availability"

[Steve Ebersole]

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 at hibernate.org
>>> http://hibernate.org
>>
>> --
>> steve at hibernate.org
>> http://hibernate.org
>
> --
> steve at hibernate.org
> http://hibernate.org

--
steve at hibernate.org
http://hibernate.org