>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.
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 o
-Original Message-
From: Graham Triggs [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 09, 2007 2:09 AM
To: Damian Marinaccio; dspace-tech@lists.sourceforge.net
Subject: Re: [Dspace-tech] dspace.cfg -- db.statementpool = true
From: Damian Marinaccio
>From dspace.
Damian et al. --
> Every day since migrating to a new server I have been getting hundreds
> of these errors:
>
> [ ... ]
>
> Any experiences with this?
Just as a data point: same errors seen, same change made, same
observation (errors have abated). Usual caution about correlation vs.
cau
Kind of hard to say.
What's happening is fairly obvious - close() has been called on the
underlying Postgres PreparedStatement object, but the
DelegatingPreparedStatement is remaining in the pool.
I would suspect that the Connection that had been used in creating the
statement has been closed at
On 09/05/07, Graham Triggs <[EMAIL PROTECTED]> wrote:
> Also, there appears to be a bug in the TableRowIterator, although this
> probably isn't affecting you. In close():
>
> results.close();
> if (results != null)
> results.close();
>
> should be:
>
> if (results != null)
> results.close()
6 matches
Mail list logo
