commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship" <hls...@comcast.net>
Subject RE: [HiveMind] DeferredService performance
Date Sun, 21 Sep 2003 13:38:11 GMT
Took me a little bit to "get" this ... the split allows the inner proxy to replace *itself*
in the
outer proxy. Clever.

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.

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 haven't had a time to deal with lifecycle manaagement yet, but 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.

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.

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.

> -----Original Message-----
> From: Christian Essl [mailto:christianessl@yahoo.de] 
> Sent: Sunday, September 21, 2003 3:44 AM
> To: commons-dev maillinglist
> Subject: [HiveMind] DeferredService performance
> 
> 
> I think the Proxy created for a deferred Service is currently 
> a bit slow, 
> because each call to a Service method first checks 
> synchronized if the 
> service is there. While the Proxy is not anymore returned 
> once the actual 
> Service is loaded I think most users of the Service will 
> still go through 
> the proxy (You know: generally early Objects live longest and 
> are most 
> used).
> 
> I would suggest the proxy to implement the GoF state pattern 
> (an idea I got 
> from commons-collection FastArrayList):
> 
> You have two proxies where the outer one contains the inner one. The 
> outerone just plainly gives further to a service field which 
> is either the 
> innter proxy or the actual loaded service. The inner proxy is 
> like the 
> current deferred proxy:
> 
> The code of a ready proxy would look like this: (This would 
> of course have 
> to be produced with JavaAssist):
> 
> public class OuterProxy implements ServiceInterface{
> 
> 	private ServiceExtenstionPointImpl _sep;
> 	private InnerProxy _inner = new InnerProxy();
> 	private ServiceInterface _service = new InnerProxy();
> 
> 	//an example method of the ServiceInterface
> 	public Object exampleMethod(Object arg){
> 		return _service.exampleMethod(arg);
> 	}
> 
> 	//the innerproxy
> 	public class InnerProxy implements ServiceInterface{
> 		//method which loads the actual service
> 		private synchronized ServiceInterface getService(){
> 			if(_service != this)
> 				return _service;
> 			_service = 
> _sep.constructServiceImplementation();
> 			return _service;			
> 		}
> 
> 		//and the exampleMethod
> 		public Object exampleMethod(Object arg){
> 			return this.getService().exampleMethod(arg);
> 		}
> 
> 	}
> }
> 
> This also prevents the - potential - method conflict that can 
> happen when a 
> ServiceInterface implements  the SERVICE_ACCESSOR_METHOD_NAME 
> (_service) 
> method.
> 
> By the way I saw this when I was looking for a way to implement basic 
> livecycle management. Have you thought of a destroy method. I 
> think it is 
> realy needed before Database, DAO, Pool, Cache, etc Services can be 
> implemented.
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


Mime
View raw message