commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Essl <>
Subject Re: [HiveMind] DeferredService performance
Date Sun, 21 Sep 2003 22:39:29 GMT
> Javassist doesn't do inner classes, so there's still going to be some 
> kind of _setService() kind of
> method used by the proxy when it replaces itself.

Thank you that's right, and as you see I don't realy know Javassist.

> I'm using "_" to indicate "infrastructure" methods, in the believe that 
> this will not cause a
> conflict. Between that, and method overloading (by parameter type) I 
> would not be too worried about
> method name conflicts.  We should document that service methods should 
> not contain method names with
> a leading underscore (perhaps enforce that as well).

I agree and would say if there is a conflict it is enforced any way (maybe 
a meaningfull exception).

????? LifeCycle ???????

Just a few things I thought about:

> I see it as an added service model,
> by leveraging ThreadEventNotifier and a ThreadLocal, much like the 
> "threaded" service model. Also,
> there should be another lifecycle interface, like Initializable, for 
> service implementations ...
> "Passivatable"? Ugh.

Yes an additional interface would be needed (It is hard for me to find a 
good name - English is not my first language).

Actually I thought initially of two other cases: First a balance to the 
startup phase where the Registry (and all the Services) are terminated. In 
this case the user has to take care that no thread uses anymore any 
services and than he calles Registry.terminate(). All ServiceModels should 
and can be stopped in this case. I think that's currently the most 
important case for ConnectionPools etc. The second case is about 
termination of certain Services during the Runntime of the Registry.

> I'm concerned about degenerate cases; what if a service, when it 
> passivates, invokes methods on
> other services, activating them? We might need a system of locks or 
> checks to handle those cases.

I would say both (of my) cases will need a dependency-registry, which 
controls the termination and checks for circularities. If a service is 
about to be stopped all the dependend services will be stopped first.  
While I think the definition of the dependencies conceptionally belongs in 
the initializeService method I would still keep it in the hivemodule.xml 
(It is just easier to implement, because Services neither know their id nor 
the id of the services they depend on or of their Factory).

Do you think this is a possible way? Is it enough?

> Actually, much like EJBs, a service which can be pooled may be interested 
> in when it is brought out
> of the pool and brought into active service for a thread, and when it is 
> passivated and stored back
> into the pool. One interface ("ServiceLifecycle"?), two methods.

Therefore (and because pooling is for my cases not the same as destorying) 
I would suggest a shutdown process like this:

1) ServiceExtensionPointImpl.destroyService() -> 
ServiceImplementationConstructor.destroyCoreService(Object coreService)

2a) CreateClassServiceConstructor() -> ((Destroyable) coreService) 

2b) InvokeFactoryServiceConstructor() -> 
ServiceImplementationFactory.destroyCoreService(Object coreService) -> 
((Destroyable) coreService).destroy();

ad 1) The ServiceExtensionPointImpl checks if the Service can be destroyed 
now (normally only if the registry is shut down). The SEPI also remembers 
the CoreServiceImpl. The Threaded takes it from the threadlocal. If the 
threaded wants to destroy (or pool) one of its CoreImpl it calls the 
ServiceImplementationConstructor with the CoreService from the threadlocal.

ad 2a) the CreateClassServiceConstructor just checks if the CoreService 
wants to be notified of destroy and notifies it.

ad 2b) the InvokeFactoryServiceConstructor gives the coreService further to 
the Factory which created it. The Factory can now do pooling etc (the 
Pooling interface depends on the factory). The factory (if it does not 
pool) must than check if the coreService wants to be informed that it is 
destroyed (alternatively it could return a boolean indicating wheter this 
check should be done by the InvokeFactoryServiceConstructor).

    Regarding the second case (unloading a Single threaded Service during 
Registry runntime) I would say we need an extra ServiceModel. It would be 
quite similar to the deferred-model but it could also change back to the 
deferred state. It also keeps a count of threads acessing the current 
Service. When asked to shutdown it first changes to the deffered state. 
Than waits until the last thread has left the (old) CoreService and than 
does the shutdown process as described above. If the service is newly 
needed it starts it like the deffered proxy.

It would be nice if you could comment on that and I would realy like to try 
implement such a thing.

View raw message