[
https://issues.apache.org/jira/browse/DERBY-3862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627898#action_12627898
]
Trejkaz commented on DERBY-3862:
--------------------------------
Okay, I figured out what was going on, but it's still a bit baffling.
One transaction would do the query and iterate through the list, but in the
middle of building the objects it would go off and do some other query in a
"separate" transaction. For various reasons ( DERBY-3675 ) when in client mode
this is the same connection, so it would squash the transaction we were still
using and as a side-effect the blobs returned from the result set.
Swapping the calls fixes it.
Presumably this is the expected behaviour, but it's still a mystery that it
works for all databases except this one which I received today.
> "You cannot invoke other java.sql.Clob/java.sql.Blob methods" on calling
> Result#getString for Clob column
> ---------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3862
> URL: https://issues.apache.org/jira/browse/DERBY-3862
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.4.1.3
> Reporter: Trejkaz
>
> I have seen this error a couple of times on the client driver v10.4.1.3
> (server is also v10.4.1.3 if it matters):
> java.sql.SQLException: You cannot invoke other
> java.sql.Clob/java.sql.Blob methods after calling the free() method or after
> the Blob/Clob's transaction has been committed or rolled back.
> at
> org.apache.derby.client.am.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:46)
> at
> org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:362)
> at org.apache.derby.client.am.Clob.length(Clob.java:239)
> at org.apache.derby.client.am.Cursor.getString(Cursor.java:1035)
> at
> org.apache.derby.client.am.ResultSet.getString(ResultSet.java:1069)
> at
> org.apache.derby.client.am.ResultSet.getString(ResultSet.java:1661)
> at (our code)
> DERBY-3583 notes the error message for the same usage but that is for
> multiple calls -- this is happening on the *first* call to getString for that
> column.
> Autocommit is off -- all access to the database in our code is funneled
> through one place, we set it to false immediately after getting it from the
> pool and there are no other calls to it.
> I have looked at another place in our code where we are getting a Clob as a
> string and in that place we are using the character stream and reading that
> to a string, and not closing it, which in itself is suspicious but maybe
> there is a reason. There is no comment saying why we're not using getString,
> but it might be because of this issue. Will be investigating that lead some
> more shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
