db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sunitha Kambhampati <ksunitha...@gmail.com>
Subject [PATCH] Derby-265 -In Network Server retrieving BLOB values with autocommit off causes NullPointerException in INSANE build /Assert failure in sane build
Date Fri, 27 May 2005 00:14:14 GMT
This patch is a fix for Derby -265. 
http://issues.apache.org/jira/browse/DERBY-265  - In Network Server 
retrieving BLOB values with autocommit off causes NullPointerException 
in INSANE build / AssertFailure in  BaseContainerHandle.getTransaction 
in SANE Build

The problem
-- Basically, in autocommit mode, when getBlob is called on a resultset 
after the transaction in which it was created is committed throws an 
NPE. Per the jdbc api and spec, getBlob is valid only for the duration 
of the transaction in which it was created.  So it is incorrect to call 
getBlob as in this repro for derby-265.
-- On a getBlob for overflow columns,  we initiliaze the stream by 
reopening the container. In here, the transaction of the containerhandle 
ends up being null and an NPE is thrown.
-- The problem is not specific to network server as such, but is 
reproducible in embedded mode also.

Fix includes
--    Adds check in  OverflowInputStream.initStream  to see if 
transaction of the container handle is null and throws a 
StandardException with SQLState.DATA_CONTAINER_CLOSED
--    And at  the jdbc layer, this exception is wrapped with a user 
exception with an existing  SQLState XJ073             
(SQLState.BLOB_ACCESSED_AFTER_COMMIT) for both getBlob and getClob.
The error message corresponding to this sqlstate is  "The data in this 
Blob or Clob is no longer available. Possible reasons are that its 
transaction committed, or its  connection closed."
--   Removed the ASSERT in BaseContainerHandle.getTransaction()

Also note, if you try to do a read on the blob when transaction closes 
(in autocommit mode), we already handle such cases and throw a similar 
error(either container is closed or that the data in blob or clob is no 
longer available )depending on the api used.

--   Added test cases to existing jdbcapi/blobclob4BLOB.java , this test 
will run in both network server and embedded mode
--   Ran derbyall on jdk142/Win2k.
All tests passed except for one test that currently fails with 
DerbyNetClient - lang/updatableResultSet.java. The diff seems to be 
difference in cursor names. This test also fails on a clean 
build(without my changes). 

svn stat
M      java\engine\org\apache\derby\impl\jdbc\EmbedBlob.java
M      java\engine\org\apache\derby\impl\jdbc\EmbedClob.java




Can someone review it, and if there are no comments can a committer 
please commit the patch.


Mike Matrigali wrote:

> I think your description below is valid.  Blob's are not valid after the
> transaction that opened them commits.  Doing interleaved result sets in
> autocommit mode is almost always a bug waiting to happen.  "Held"
> cursors help some, but still after the commit you must do a next - the
> current blob is not valid.
> A NPE is not a good error, but if possible I would like to see the
> catch of the error condition pushed as high up in the code as possible.
> Is it possible for the jdbc getBlob() call to recognize that the
> transaction of the blob has closed?  If not then maybe at least the
> catch can be placed in the blob datatype itself, it may just have to
> check every time it accesses store to get the next piece of the blob -
> or better performing would be to assume the point is good and have
> a try/catch to catch the error and turn it into a more reasonable
> user level error.
> Sunitha Kambhampati wrote:
>> I am actually looking at Derby 265 (an assert failure in store).  The 
>> assert failure occurs on a getBlob call which is because at that time 
>> there is no transaction context.  But then, looking at the repro got 
>> me thinking about select stmt in autocommit mode and also wonder if 
>> the repro is testing the right behavior or not..
>> Section 10.1 of the JDBC 3.0 spec says
>> Enabling autocommit,  causes the jdbc driver to do a transaction 
>> commit after each individual sql statement as soon as it is 
>> complete.  the point at which it is complete depends on type of 
>> statement.  for select statement  :- statement is complete when 
>> resultset is closed and result set is closed* as soon as one* of the 
>> following happens
>>   -- all rows have been retrieved
>>  -- associated statement object is re-executed
>>  -- another Statement object is executed on the same connection
>> from repro in  Derby-265 :
>> Note s, s2 are on the same connection object that is in  autocommit mode
>> 1    s.execute("select * from maps")
>> 2    rs1 = s.getResultSet();
>> 3    s2.execute("select * from maps")        4    rs2 = 
>> s2.getResultSet();                    5    rs2.next();
>> 6    rs2.getBlob(6);
>> 7    rs1.close();
>> 8    rs2.next();
>> 9    rs2.getBlob(6);           __________________
>> -- from the spec (10.1) , does it mean that the statement execution 
>> on line 3 would commit the earlier statement on #1.   ? If so, we 
>> dont seem to do that.
>> -- Also, rs1.close() is internally calling a commit but the 
>> connection is actually dealing with s2 currently and  so is it right 
>> that rs1.close() commits the transaction associated with s2 ?   Then 
>> again, is this interleaving of reading of resultsets and select 
>> statement even valid ? . I checked the jdbc spec and the api and also 
>> briefly the tutorial book but didnt come across much about this. .
>> Coming back to the reason for the assert failure
>> -- so rs1.close() is committing the transaction which is why 
>> rs2.getBlob(6) is left without a transaction context leading to the 
>> assert failure.
>> A simpler snippet for just the assert failure case (s ,s1 on one 
>> connection in autocommit mode).
>> 1    s.execute("select * from maps'");
>> 2    rs = s.getResultSet();
>> 3    s1.executeUpdate("insert ....  ");
>> 4    rs.next();
>> 5    rs.getBlob(6);
>> -- when s1 is executed , s is complete ( and committed ) per spec.  
>> Will rs still be valid at (line 4), I guess that depends on the 
>> holdability.  As rs is a hold cursor, what transaction context should 
>> this be in  ?
>> -- The assert failure happens on the getBlob call ( line 5) , which 
>> is because the blob has an underlying outputstream and uses a 
>> transaction context in this case.
>> The jdbc api for Blob says ' A blob object_ is valid for the 
>> duration* *of the transaction in which* *it was created_*'*.  From 
>> this it seems like the call on #5  is actually not valid ( since the 
>> transaction in which the blob was created is complete).
>> -- All this makes me think that the program is incorrect.  But I 
>> guess  we should be throwing  a  better user error instead of an 
>> npe/assert.
>> ___________________
>> Also some notes on derby 265.
>> -- repro violated this part of the jdbc api for Statement
>> "By default, only one |ResultSet| object per |Statement| object can 
>> be open at the same time. Therefore, if the reading of one 
>> |ResultSet| object is interleaved with the reading of another, each 
>> must have been generated by *different |Statement| objects*. All 
>> execution methods in the |Statement| interface implicitly close a 
>> statment's current |ResultSet| object if an open one exists"
>> So  made changes to use different Statement objects.
>> -- The derby 265 assert failure cause  is not specific to network 
>> server mode as such. In the original repro, getBlob()  was not being 
>> called in the program which is why embedded was not throwing the 
>> error,  but for network server a rs2.next() actually retrieves the 
>> blob (getBlob()) which causes the assert to be thrown at the store 
>> level.  So changing the program to call rs2.getBlob shows up the 
>> error in embedded mode also.
>> -- Note, the assert failure happens only if the blob column overflows
>> I'd appreciate any comments/feedback.
>> Thanks,
>> Sunitha.

View raw message