cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johannes Textor <>
Subject Re: REPOST: Database connection "overload"
Date Wed, 04 Jun 2008 11:42:09 GMT

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.


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 <>, Johannes
Textor <> 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:
For additional commands, e-mail:

View raw message