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