Johannes OK - and I assume the } finally { //close connection } won't throw an error if the connection is *not* open?
PS If there are any "low entry barriers" (i.e. not getting into Java, or having to rewrite everything for Hibernate...) to improving this approach, I would be very happy to hear about them. Thanks Derek >>> On 2008/06/04 at 01:42, in message <[EMAIL PROTECTED]>, Johannes Textor >>> <[EMAIL PROTECTED]> wrote: 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 -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]