[
https://issues.apache.org/jira/browse/DERBY-4312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732624#action_12732624
]
Kathey Marsden commented on DERBY-4312:
---------------------------------------
Lob.java has:
protected int dataType_ = 0; // data type(s) the LOB instance currently
contains
which can include:
public static final int STRING = 2;
public static final int ASCII_STREAM = 4;
public static final int UNICODE_STREAM = 8;
public static final int CHARACTER_STREAM = 16;
public static final int BINARY_STREAM = 32;
public static final int BINARY_STRING = 64;
public static final int LOCATOR = 128;
A quick change to only do the transaction check in Lob.checkValidity() if
isLocator() is true seems to resolve the issue and jdbcapi.BlobClob4BlobTest
passes so the intended DERBY-3574 check seems to still work since a test was
added for that. I am not totally sure if this is too liberal though and would
appreciate input. Meanwhile I will add a test and run the rest of regressions
with this simple fix.
> SQLException XJ215 on insert with setCharacterStream() and autocommit off in
> mailjdbc test
> -------------------------------------------------------------------------------------------
>
> Key: DERBY-4312
> URL: https://issues.apache.org/jira/browse/DERBY-4312
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.4.2.0, 10.5.1.1, 10.5.2.0, 10.6.0.0
> Environment: SuSE Linux IBM 1.6 SR4
> Reporter: Kathey Marsden
> Attachments: create.sql, ReproDerby4312.java
>
>
> I am running the 10.5 maildbc test on Linux with network server and the
> 10.5.2.0 release candidate and an updated derbyTesting.jar to have just
> Lily's change to change the backup user: I see in the test output early and
> often, this error inserting data into the table:
> SQLState: XJ215
> Severity: 20000
> Message: You cannot invoke other java.sql.Clob/java.sql.Blob methods after
> calling the free() method or after
> Clob's transaction has been committed or rolled back.
> java.sql.SQLException: You cannot invoke other java.sql.Clob/java.sql.Blob
> methods after calling the free() m
> ter the Blob/Clob's transaction has been committed or rolled back.
> at
> org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown
> Source)
> at org.apache.derby.client.am.SqlException.getSQLException(Unknown
> Source)
> at org.apache.derby.client.am.Lob.checkValidity(Unknown Source)
> at org.apache.derby.client.am.Clob.length(Unknown Source)
> at
> org.apache.derby.client.net.NetStatementRequest.computeProtocolTypesAndLengths(Unknown
> Source)
> at
> org.apache.derby.client.net.NetStatementRequest.buildSQLDTAcommandData(Unknown
> Source)
> at
> org.apache.derby.client.net.NetStatementRequest.writeExecute(Unknown Source)
> at
> org.apache.derby.client.net.NetPreparedStatement.writeExecute_(Unknown Source)
> at org.apache.derby.client.am.PreparedStatement.writeExecute(Unknown
> Source)
> at org.apache.derby.client.am.PreparedStatement.flowExecute(Unknown
> Source)
> at org.apache.derby.client.am.PreparedStatement.executeUpdateX(Unknown
> Source)
> at org.apache.derby.client.am.PreparedStatement.executeUpdate(Unknown
> Source)
> at
> org.apache.derbyTesting.system.mailjdbc.utils.DbTasks.insertMail(DbTasks.java:447)
> at
> org.apache.derbyTesting.system.mailjdbc.tasks.Refresh.insertMail(Refresh.java:99)
> at
> org.apache.derbyTesting.system.mailjdbc.tasks.Refresh.doWork(Refresh.java:75)
> at
> org.apache.derbyTesting.system.mailjdbc.tasks.Refresh.run(Refresh.java:51)
> Caused by: org.apache.derby.client.am.SqlException: You cannot invoke other
> java.sql.Clob/java.sql.Blob metho
> lling the free() method or after the Blob/Clob's transaction has been
> committed or rolled back.
> The interesting thing is that the test itself is not using any Clob methods
> it uses setCharacterStream and also autocommit is off.
> Below is a code excerpt and
> conn.setAutoCommit(false);
> PreparedStatement insertFirst = conn.prepareStatement(
> Statements.insertStr, Statement.RETURN_GENERATED_KEYS);
> String name = new String("ABCD");
> String l_name = new String("WXYZ");
> long s_insert = System.currentTimeMillis();
> for (int i = 0; i < num; i++) {
> String new_name = new String(increment(name, 60));
> String new_lname = new String(decrement(l_name, 60));
> insertFirst.setString(1, new_name);
> insertFirst.setString(2, new_lname);
> insertFirst.setTimestamp(3, new Timestamp(System
> .currentTimeMillis()));
> name = new_name;
> l_name = new_lname;
> try {
> // to create a stream of random length between 200 bytes
> and 3MB
> int clobLength = Rn.nextInt(3078000 - 200 + 1) + 200;
> streamReader = new LoopingAlphabetReader(clobLength,
> CharAlphabet.modernLatinLowercase());
> insertFirst.setCharacterStream(4, streamReader,
> clobLength);
> } catch (Exception e) {
> MailJdbc.logAct.logMsg(LogFile.ERROR + thread_name + " : "
> + "File not found Exception : " + e.getMessage());
> errorPrint(e);
> throw e;
> }
> int rand_num = Rn.nextInt(10 - 1);
> if (i == rand_num) {
> ResultSet rs = stmt
> .executeQuery("select count(*) from REFRESH.INBOX
> where attach_id>0");
> while (rs.next()) {
> id_count = rs.getInt(1);
> insertFirst.setInt(5, rs.getInt(1) + 1);
> }
> rs.close();
>
> conn.setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED);
> } else
> insertFirst.setInt(5, 0);
> insertFirst
> .setString(
> 6,
> "This column is used only to by pass the space
> problem. If the problem still exists, then we are going to "
> + "have a serious issue
> here.*****************************************************************************************************");
> int result = insertFirst.executeUpdate();
> if I connect with ij I do see some rows in the INBOX, so some inserts do seem
> to be happening.
> Kristian pointed out that this looks similar to DERBY-4224 with
> setAsciiStream() but this looks far more serious as autocommit is off and
> there does not appear to be a commit, so there is no obvious workaround. I
> assume this is also a regression. We shouldn't be throwing this error if the
> user did not use any Clob methods. I will try to narrow down the
> reproduction and track down where the issue was introduced. Knut said
> DERBY-4224 goes all the way back to 10.3.1.4 with DERBY-208. I don't know if
> it is the same case with this one.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
