------=_Part_3059_24618743.1210308089765
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Hi Kris
Thanks for the quick response.
No the app is not multithreaded. It's a web app and I'm the only user on
my
local test PC. So I start tomcat, run a single post which generates the
error, stop tomcat.
I didn't understand your 2nd point. When I call
PreparedStatement.executeUpdate() I have to know that the row did or did
not
get written. If there is a situation that an exception can be thrown after
the data has been written, that exception needs to be unambiguous in
telling
the caller that the data is written or not.
I'm happy to provide any debug/logs which help you with this one, just let
me know.
best
Roy
On Fri, May 9, 2008 at 5:14 AM, Kris Jurka <books@[EMAIL PROTECTED]
> wrote:
>
>
> On Fri, 9 May 2008, Roy Smith wrote:
>
> I have an app which inserts rows to a table called messages. During
load
>> testing, I'm looping to insert 10,000 rows. Intermittentently (around
5% and
>> only after the first 6,000 or so) I'm getting the following
Exception...
>>
>> org.postgresql.util.PSQLException: This statement has been closed.
>> at
>>
>>
org.postgresql.jdbc2.AbstractJdbc2Statement.checkClosed(AbstractJdbc2Statement.java:2442)
>> at
>>
>>
org.postgresql.jdbc2.AbstractJdbc2Statement.getUpdateCount(AbstractJdbc2Statement.java:495)
>> at
>>
>>
org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:309)
>> at
com.primetext.tl2000.dataobjects.Messages.insert(Messages.java:566)
>>
>> This smells like a bug. There are other updates within my loop, and I
>> can't promise that I'm closing all statements. Therefore if this bug is
>> being triggered by me abusing the driver, please confirm and I'll go
through
>> all of my code ensuring that all preparedstatements are being closed.
>>
>>
> Is your app multi-threaded? The only way I see for this to happen is
that
> one thread is executing the statement and another is closing it.
>
> However, there is a another aspect of this which smells like an even
>> bigger bug... Even though the PreparedStatement.executeUpdate is
throwing an
>> exception, the row *is* being written to the database!! This can't
possibly
>> be valid.
>>
>>
> The exception is from the driver, not the server and it happens after
the
> query has been executed by the server. Once the server has committed
the
> data, there's not much the driver can do about that.
>
> Kris Jurka
>
------=_Part_3059_24618743.1210308089765
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Hi Kris<br><br>Thanks for the quick response. <br><br>No the app is not
multithreaded. It's a web app and I'm the only user on my local
test PC. So I start tomcat, run a single post which generates the error,
stop tomcat.<br>
<br>I didn't understand your 2nd point. When I call
PreparedStatement.executeUpdate() I have to know that the row did or did
not get written. If there is a situation that an exception can be thrown
after the data has been written, that exception needs to be unambiguous in
telling the caller that the data is written or not.<br>
<br>I'm happy to provide any debug/logs which help you with this one,
just let me know.<br><br>best<br>Roy<br><br><br><br><div
class="gmail_quote">On Fri, May 9, 2008 at 5:14 AM, Kris Jurka <<a
href="mailto:books@[EMAIL PROTECTED]
">books@[EMAIL PROTECTED]
>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204,
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div
class="Ih2E3d"><br>
<br>
On Fri, 9 May 2008, Roy Smith wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204,
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I have an app which inserts rows to a table called messages. During load
testing, I'm looping to insert 10,000 rows. Intermittentently (around
5% and only after the first 6,000 or so) I'm getting the following
Exception...<br>
<br>
org.postgresql.util.PSQLException: This statement has been closed.<br>
at<br>
org.postgresql.jdbc2.AbstractJdbc2Statement.checkClosed(AbstractJdbc2Statement.java:2442)<br>
at<br>
org.postgresql.jdbc2.AbstractJdbc2Statement.getUpdateCount(AbstractJdbc2Statement.java:495)<br>
at<br>
org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:309)<br>
at
com.primetext.tl2000.dataobjects.Messages.insert(Messages.java:566)<br>
<br>
This smells like a bug. There are other updates within my loop, and I
can't promise that I'm closing all statements. Therefore if this
bug is being triggered by me abusing the driver, please confirm and
I'll go through all of my code ensuring that all preparedstatements are
being closed.<br>
<br>
</blockquote>
<br></div>
Is your app multi-threaded? The only way I see for this to happen is
that one thread is executing the statement and another is closing it.<div
class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204,
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
However, there is a another aspect of this which smells like an even
bigger bug... Even though the PreparedStatement.executeUpdate is throwing
an exception, the row *is* being written to the database!! This can't
possibly be valid.<br>
<br>
</blockquote>
<br></div>
The exception is from the driver, not the server and it happens after the
query has been executed by the server. Once the server has committed
the data, there's not much the driver can do about that.<br><font
color="#888888">
<br>
Kris Jurka<br>
</font></blockquote></div><br>
------=_Part_3059_24618743.1210308089765--
|
