Monday, December 15, 2003, 12:37:43 AM, Stephen McConnell wrote:
> Daniel Dekany wrote:
>
>>Sunday, December 14, 2003, 5:34:45 PM, Niclas Hedhman wrote:
>>
>>[snip]
>>
>>
>>>>But the real problem with "release always" is that explicitly releasing
>>>>all components is a big PITA. try{...}finally{release},
>>>>try{...}finally{release}, try{...}finally{release}...
>>>>
>>>>
>>>I am not saying that we scrap Stephen's approach, but leverage on it. By
>>>requiring release(), yet depend on automatic reclamation, we get both side
>>>satisfied, no?
>>>You don't need the try{}finall{ release}, since the times when the exception
>>>is thrown is so seldom that you can safely rely on the automatic reclamation,
>>>
>>>
>>
>>I don't think so... however, I admit I'm bit paranoid. :) Consider, some
>>long-term malfunction occurs, e.g. a DB server is stopped, so *all*
>>operation that tries to access that will throw exception. As a result of
>>that, a component pool dries out (since the components are not
>>explicitly released, and GC has long delays), and requests that need
>>that will wait very long for the pool, which will quickly result in
>>traffic jam.
>>
>
> I disagee ...
>
> Fred fred = null;
> try
> {
> fred = (Fred) m_manager.get( "fred" );
>
> //
> // do stuff
> //
> }
> catch( Throwable e )
> {
> // do other stuff
> }
> finally
> {
> //
> // explicit release whatever happens
> //
>
> m_manager.release( fred );
> }
>
> The "finally" clause is gaurantee to run on success or failure.
>
> Stephen.
I have reacted on Niclas Hedhman's "You don't need the try{}finall{
release}, since the times when the exception is thrown is so seldom that
you can safely rely on the automatic reclamation,"... i.e. that it is
not good if there is NO finally.
--
Best regards,
Daniel Dekany
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
