You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Derek Hohls <DH...@csir.co.za> on 2008/05/27 09:15:26 UTC
Database connection "overload"
Running Cocoon 2.1.8
It seems to be the case that, when the number of allowed database connections
are exceeded (called by a "getConnection" in flowscript), the application will then
hang - is there any mechanism to detect and avoid this condition - and is there
any means to "reboot" the application without restarting the servlet container
(which affects all the other applications which are running)?
Thanks
Derek
--
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: REPOST: Database connection "overload"
Posted by Johannes Textor <jc...@gmx.de>.
Derek Hohls schrieb:
> Johannes
>
> OK - and I assume the
> } finally {
> //close connection
> }
> won't throw an error if the connection is *not* open?
>
It would throw an error in this case, but you could check if the
connection is open before closing it. However, the error would not be
harmful by leaving any open connections.
> 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.
>
I'm not sure if I have anything to recommend - accessing the DB directly
from flowscript is usually considered messy for a reason. But since I
have done this myself in the past when I just tried to "get things done"
quickly with the few things I knew about cocoon, I'm pretty sure there
are still lots of people out there who do this, even though it's not
supposed to be done like this.
Whatever, something I tried to avoid these complications was to
implement the Data Access Object pattern in flowscript to abstract away
the JDBC calls and push them to a central location. (Yes, you can write
nice object oriented code in Javascript, too). This way I just had to
debug these DAO classes for unclosed connections. I tried to make sure
my methods were atomary transactions, that is, a JDBC connection was
opened at the beginning of the method and closed at the end of it. Maybe
this approach would be something for you to try, if you don't want to go
and implement an Open Session in View filter in Java, which is still the
most elegant solution to the problem by far, but unfortunately can't be
done in flowscript AFAIK.
Regards,
Johannes
> Thanks
> Derek
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: REPOST: Database connection "overload"
Posted by Derek Hohls <dh...@csir.co.za>.
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 <48...@gmx.de>, Johannes Textor <jc...@gmx.de> 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 <48...@gmx.de>, Johannes Textor <jc...@gmx.de> 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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: REPOST: Database connection "overload"
Posted by Johannes Textor <jc...@gmx.de>.
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 <48...@gmx.de>, Johannes Textor <jc...@gmx.de> 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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: REPOST: Database connection "overload"
Posted by Derek Hohls <dh...@csir.co.za>.
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 <48...@gmx.de>, Johannes Textor <jc...@gmx.de> 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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: REPOST: Database connection "overload"
Posted by Johannes Textor <jc...@gmx.de>.
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: REPOST: Database connection "overload"
Posted by Derek Hohls <dh...@csir.co.za>.
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?
Thanks
Derek
>>> On 2008/06/04 at 11:18, in message <48...@gmx.de>, Johannes Textor <jc...@gmx.de> wrote:
Derek,
the only condition I am aware of which might make the application
"freeze" is when connections are not properly closed and returned to the
connection pool. Could you post the javascript code you use to obtain a
connection from the DB and then close it ?
Regards,
Johannes
Derek Hohls schrieb:
> Anyone have any ideas on this?
>
>
>>>> On 2008/05/27 at 09:15, in message <48...@csir.co.za>, "Derek Hohls" <DH...@csir.co.za> wrote:
>>>>
> Running Cocoon 2.1.8
>
> It seems to be the case that, when the number of allowed database connections
> are exceeded (called by a "getConnection" in flowscript), the application will then
> freeze - is there any mechanism to detect and avoid this condition - and is there
> any means to "reboot" the application without restarting the whole servlet container
> (which affects all the other Cocoon applications which are running there)?
>
> Thanks
> Derek
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
--
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: REPOST: Database connection "overload"
Posted by Johannes Textor <jc...@gmx.de>.
Derek,
the only condition I am aware of which might make the application
"freeze" is when connections are not properly closed and returned to the
connection pool. Could you post the javascript code you use to obtain a
connection from the DB and then close it ?
Regards,
Johannes
Derek Hohls schrieb:
> Anyone have any ideas on this?
>
>
>>>> On 2008/05/27 at 09:15, in message <48...@csir.co.za>, "Derek Hohls" <DH...@csir.co.za> wrote:
>>>>
> Running Cocoon 2.1.8
>
> It seems to be the case that, when the number of allowed database connections
> are exceeded (called by a "getConnection" in flowscript), the application will then
> freeze - is there any mechanism to detect and avoid this condition - and is there
> any means to "reboot" the application without restarting the whole servlet container
> (which affects all the other Cocoon applications which are running there)?
>
> Thanks
> Derek
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
REPOST: Database connection "overload"
Posted by Derek Hohls <dh...@csir.co.za>.
Anyone have any ideas on this?
>>> On 2008/05/27 at 09:15, in message <48...@csir.co.za>, "Derek Hohls" <DH...@csir.co.za> wrote:
Running Cocoon 2.1.8
It seems to be the case that, when the number of allowed database connections
are exceeded (called by a "getConnection" in flowscript), the application will then
freeze - is there any mechanism to detect and avoid this condition - and is there
any means to "reboot" the application without restarting the whole servlet container
(which affects all the other Cocoon applications which are running there)?
Thanks
Derek
--
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org