Andrzej Jan Taramina wrote:
One reason is performance. While the overhead caused by the proxy itself is minimal, under the covers there would be a call to Handle.access() and Handle.release() on each method invocation. Now, let's say that a client needs to make 10 method calls on a particular service during one request. Wouldn't it make sense to acquire the service instance only once?Antti responds:So, the Handle interface is there to provide consistent access to all shared services that allow unsynchronized implementations. Now, this still leaves the issues of hot deploying thread-safe services, for which me might have to use dynamic proxies, but this isn't something the client has to worry about.
Why not use a service proxy object instead of a handle, in those situation where you need a handle? That might be a more elegant solution, since the application would always think it had a 1st class object, though under the covers it might actually be a proxy that provided the additional semantics needed for threaded services?
Typically the difference in performance would be small, but this is not always the case. A service implementation might need to acquire a database connection and a large data set to perform its other operations, possibly based on input received from the client. This also leads us to the second reason: the service might want to maintain state between the calls to access() and release().
I hope this makes sense, and sorry for not being clear before.
(: A ;)
--
Antti Koivunen (Mr.) <[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
