[hibernate-dev] Concept of "service availability"

Mon Aug 27 13:34:31 EDT 2012

Not sure this will actually help with OSGi in terms of auto-discovery 
at all after thinking about it some more.  The problem is that in order 
for auto-discovery to happen, Hibernate would need to have visibility 
into the jar defining the service anyway in order to auto-discovery it.

On the bright side, I realized another benefit.  It would finally be 
possible to report the available types of a particular 
service/strategy.  For example, show me all the available 
ConnectionProviders; all the available Dialects; etc...

On Fri 24 Aug 2012 08:51:09 PM CDT, Steve Ebersole wrote:
> 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

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