Derek,
you should use the power of the finally construct, which is also
available in JS:
function accessDB() {
try {
//get connection
//do stuff...
//return result
} catch(e) {
cocoon.log.error ("Unable to complete function accessDB");
return null;
} finally {
//close connection
}
}
The finally block is meant to contain instructions which must *always*
be executed, no matter what happens in the try and catch blocks.
Regardless of that, having hundreds of different places where
connections are opened and closed in flowscript seems like a bad idea.
Regards,
Johannes
Derek Hohls schrieb:
> Johannes
>
> Thanks for the detailed insight into issues. I had hoped to avoid
> patching hundreds of functions. but I guess its inevitable.
>
> Would a function like the following be able to avoid the problem
> I have been having:
>
> function accessDB() {
> try {
> //get connection
> //do stuff...
> //close connection
> //return result
> } catch(e) {
> cocoon.log.error ("Unable to complete function accessDB");
> return null;
> }
> }
>
> (I'm not sure how this will ensure the connection is closed?)
>
> Thanks
> Derek
>
>
>
>>>> On 2008/06/04 at 12:28, in message <[EMAIL PROTECTED]>, Johannes Textor
>>>> <[EMAIL PROTECTED]> wrote:
>>>>
> Derek Hohls schrieb:
>
>> Johannes
>>
>> This was my thought too. I have numerous modules & functions that
>> open (and should close!) connections. On manual inspection they all
>> seem to be OK, but possibly there is one somewhere which is not correct.
>> Hence my need to try and prevent this; or have the system in some way
>> report exactly when & where this is happening so I can fix the offending
>> code. Any ideas on how to do this?
>>
>>
> I am not aware of any method which would allow one to inspect the
> current state of the pool. Perhaps the best way would be to log any
> opening and closing of connections, including the name of the component
> which uses them, and scan the log files for connections which are not
> correctly closed. The problem is in the design itself (opening and
> closing JDBC connections in several places scattered around the
> application) which makes such applications a mess to debug (been through
> it myself).
>
> A common source for this problem is when error messages get thrown which
> interrupt the execution of the flow script. Unless you use something
> like the OpenSessionInViewFilter which gets rid of this kind of problem,
> in the case of an unexpected error your connections normally remain
> open. This means that after 10 error messages or so your pool is
> exhausted and you're stuck.
>
> If you are not the kind of Java guy to implement the Open Session in
> View Concept (which should work with JDBC connections too, not just
> Hibernate Sessions), I'd recommend you use the try - catch - finally
> idiom in *every* flowscript function which uses a JDBC connection.
>
> Regards,
> Johannes
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
