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] New service-model hot-replace/shut-down
Date Tue, 30 Sep 2003 12:25:07 GMT
What triggers the service model to reload and rebuild the service implementation?

--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com

> -----Original Message-----
> From: Christian Essl [mailto:christianessl@yahoo.de] 
> Sent: Tuesday, September 30, 2003 7:28 AM
> To: commons-dev@jakarta.apache.org
> Subject: [HiveMind] New service-model hot-replace/shut-down
> 
> 
> I'd like to suggest a new service-model, which allows to 
> replace and/or 
> shut-down a service-implementation at runtime. (The latest 
> refactoring 
> makes this much easier).
> 
> The model works basicly like the deferred-model (except that 
> it always 
> returns the proxy). Initially it is in the deferred state and 
> when the 
> first request comes it creates the implementation. Different to the 
> deffere-model all metods are sychronized with a acquireRead() 
> read on a 
> read-write-lock (reads go unsychnorinzed until some one 
> aquires the write). 
> When the user wants to shutdown or replace the implementation, the 
> ServiceExtensionPoint aquires the write-lock. Now all current 
> service- 
> method-calls can finish and furthers are blocked. Than the proxy just 
> switches back to the deffered state and does the clean-up on 
> the service- 
> implementation. In case of hot-replace the ServiceExtensionPoint also 
> replaces the ServiceImplementationConstructor. Than the write-lock is 
> released and if a new call comes in the (new)implementation 
> is created 
> again.
> 
> I would say the management could happen through a special 
> service at which 
> all the hot-replace extension points register.
> 
> I think this allows shut-down and replace during run-time and 
> that it is 
> totally transparent to the whole application. I'm quite sure 
> there are also 
> no threading issues. As I see the only dissadvantage is that 
> it slows down 
> the service a bit.
> 
> It could be useful for testing and ie togehter with a timer 
> for services 
> which are rearly used but consume quite a lot of resources.
> 
> If there is any intrest I could try to implement such a service-model.
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> 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