Graham,
Thank you very much for your response.
I assumed that it was something similar to your explanation, but let me
get to the real reason for asking.
Every day since migrating to a new server I have been getting hundreds
of these errors:
Exception:
org.postgresql.util.PSQLException: This statement has been closed.
at
org.postgresql.jdbc2.AbstractJdbc2Statement.checkClosed(AbstractJdbc2Sta
tement.java:2442)
at
org.postgresql.jdbc2.AbstractJdbc2Statement.setString(AbstractJdbc2State
ment.java:1226)
at
org.apache.commons.dbcp.DelegatingPreparedStatement.setString(Delegating
PreparedStatement.java:131)
at
org.apache.commons.dbcp.DelegatingPreparedStatement.setString(Delegating
PreparedStatement.java:131)
at
org.dspace.storage.rdbms.DatabaseManager.loadParameters(DatabaseManager.
java:1724)
at
org.dspace.storage.rdbms.DatabaseManager.queryTable(DatabaseManager.java
:157)
at
org.dspace.storage.rdbms.DatabaseManager.querySingleTable(DatabaseManage
r.java:447)
at
org.dspace.storage.rdbms.DatabaseManager.querySingleTable(DatabaseManage
r.java:465)
at
org.dspace.storage.rdbms.DatabaseManager.findByUnique(DatabaseManager.ja
va:647)
at
org.dspace.storage.rdbms.DatabaseManager.find(DatabaseManager.java:612)
at org.dspace.content.Community.find(Community.java:144)
at
org.dspace.handle.HandleManager.resolveToObject(HandleManager.java:267)
at
org.dspace.app.webui.servlet.HandleServlet.doDSGet(HandleServlet.java:13
5)
at
org.dspace.app.webui.servlet.DSpaceServlet.processRequest(DSpaceServlet.
java:151)
at
org.dspace.app.webui.servlet.DSpaceServlet.doGet(DSpaceServlet.java:99)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
e.java:228)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
e.java:175)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
:104)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:2
16)
at
org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
at
org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283)
at
org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767)
at
org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:
697)
at
org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.
java:889)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool
.java:686)
at java.lang.Thread.run(Thread.java:595)
It is not always the same error trace but always the same Exception:
org.postgresql.util.PSQLException: This statement has been closed.
The only way to make this stop was to stop/restart tomcat.
Yesterday I set db.statementpool = false...
I have yet to see an error in 18 hours or so.
Any experiences with this?
Thanks again,
Damian Marinaccio
RIT Libraries
[EMAIL PROTECTED]
585-475-7741
-----Original Message-----
From: Graham Triggs [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 09, 2007 2:09 AM
To: Damian Marinaccio; [email protected]
Subject: Re: [Dspace-tech] dspace.cfg -- db.statementpool = true
From: Damian Marinaccio
>From dspace.cfg:
>--------------------------------
># Determine if prepared statement should be cached. (default is true)
>db.statementpool = true
>
>--------------------------------
>
>I cannot find ANY documentation related to this statement. What are the
>implications of turning it off/on.
Hi,
Well, as it says that the default is true, the first implication is that
you
can't turn it on - you can only turn it off ;-)
What it relates to is whether PreparedStatement objects are held in a
pool
(managed by DBCP).
Exact behaviour is rather dependent on the actual JDBC driver
implementation, but pooling PreparedStatements is meant to eliminate the
overhead of creating cursors and prevent repeated statement
parsing/creation
(I say meant - early Postgres drivers didn't hold cursors open on the
database, and only pretended to support PreparedStatement).
So, a pool of PreparedStatement objects is generally a good thing - not
having one will increase the execution time of frequently executed
(parametized) SQL, and waste significant resources on the database in
parsing, etc.
That said, maintaining open cursors on the database also takes
resources. In
particular, with some databases (ie. Oracle) the default statement
pooling
behaviour via DBCP as implemented in DSpace can overwhelm the database's
defined ability to hold open cursors, resulting in errors.
Turning off statement pooling will reduce the open cursors on the
database
(which as seen above may be useful in some scenarios), at the cost of
increasing the time and processing involved with executing each SQL
query
(reducing scalability).
What is missing from the current DSpace implementation is a
configuration
option to limit the number of PreparedStatement objects that get pooled
(which is what is ideally required to strike a balance between holding
open
resources on the database and system scalability).
G
This email has been scanned by Postini.
For more information please visit http://www.postini.com
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
DSpace-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
