db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik" <Dag.Wan...@Sun.COM>
Subject Re: DERBY-213 IRC Chat :ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server
Date Wed, 01 Jun 2005 16:12:04 GMT


>>>>> "KM" == Kathey Marsden <kmarsdenderby@sbcglobal.net> wrote:

KM> Attached are the transcripts from the  chat.  Next meeting is Thursday,
KM> June 2, 9am PST . 
KM> If you made it this far, I am looking for input on summaries for IRC chats..
KM>     * Is this too much / too little detail.
KM>     * Are the transcripts at all helpful?  I think I might drop them if
KM> they are not useful.

I, for one, like this approach (IRC) and format (your summary). The
summary let's me decide if I want to read the rest. Reading the
dialogue provides pointers for understanding Derby better. It's like
listening in on hallway conversations in real life; useful for
catching stuff one would otherwise miss, including understanding how
others work in practice. As for volume (weekly or per chat), I am fine
with either.



KM>     * Would a weekly summary be better?
KM> Thanks
KM> Kathey
KM> kmarsden good morning Philip
KM> Bogomips_ Morning
KM> kmarsden how are your tests?
KM> Bogomips_ Much more promising
KM> Bogomips_ Total of 594 tests, 92 of which fail. For what looks like legitimate reasons.
KM> Bogomips_ This is for derbyAll
KM> kmarsden What fails?
KM> Bogomips_ Many of the dml tests that were running before as well as the netmat tests.
KM> Bogomips_ However this was before I new of removing the trace, so you might be able
to cut down on those failures as well.
KM> kmarsden did you see my note about not using  ij.exceptionTrace=true
KM> kmarsden ok
KM> Bogomips_ :-)
KM> kmarsden What fails in derbynetmats
KM> kmarsden ?
KM> Bogomips_ derbyall/derbynetclientmats/derbynetclientmats.fail:derbynet/netxaPositive.sql

KM> Bogomips_ derbyall/derbynetclientmats/derbynetmats.fail:derbynet/NSinSameJVM.java 
KM> Bogomips_ derbyall/derbynetclientmats/derbynetmats.fail:derbynet/badConnection.java

KM> Bogomips_ derbyall/derbynetclientmats/derbynetmats.fail:derbynet/callable.java 
KM> Bogomips_ derbyall/derbynetclientmats/derbynetmats.fail:derbynet/checkSecMgr.java 
KM> Bogomips_ derbyall/derbynetclientmats/derbynetmats.fail:derbynet/csPrepStmt.java 
KM> Bogomips_ derbyall/derbynetclientmats/derbynetmats.fail:derbynet/dblook_test_net.java

KM> Bogomips_ derbyall/derbynetclientmats/derbynetmats.fail:derbynet/dataSourcePermissions_net.java

KM> Bogomips_ among others.
KM> kmarsden do you know why yet?
KM> kmarsden oh this is probably because you do not have db2jcc.jar and db2jcc_license_c.jar
KM> kmarsden in your classpath
KM> Bogomips_ Some of them complain about a lack of master file.  Another has a security
KM> kmarsden hmmm
KM> kmarsden derbynetclientmats is ok?
KM> Bogomips_ There were a lot of netclient problems, but I'm looking at the tests prior
to removing your the trace.
KM> Bogomips_ Shall I try removing the trace for just the singular resultset test?
KM> kmarsden The trace I am quite sure does not affect the network server tests.  I run
those just about every day
KM> kmarsden It had been a while since I had run derbyAll so that is why I hit the nist
KM> kmarsden But yes, let's work on resultset.java and then you can look at your test failures
later today.
KM> kmarsden and ping me if you have questions.
KM> kmarsden Does that sound ok?
KM> Bogomips_ Sure, sounds good.
KM> kmarsden ok. first we run resultset.java for embedded
KM> Bogomips_ k
KM> kmarsden oh I have an outdated copy.  Is the one you mailed me the latest.
KM> Bogomips_ ?
KM> Bogomips_ This is from the second email I sent you?
KM> kmarsden there was a mail delay. I have the one from Jira but I will look for your
mail now
KM> Bogomips_ Ok, should be titled "Derby-213 files May 31, 10:00 a.m. AST"
KM> kmarsden 5:46 am yesterday. Is that right?
KM> kmarsden no 6:07
KM> Bogomips_ Ya, that would be the time on it.
KM> kmarsden Attempt to shutdown framework: DerbyNetClient
KM> kmarsden 1a2,8
KM> kmarsden > Begin ImplicitClose tests
KM> kmarsden > 1
KM> kmarsden > 2
KM> kmarsden > Final call to ResultSet.next()
KM> kmarsden > Call to ResultSet.next() thows the following exception:
KM> kmarsden > org.apache.derby.client.am.SqlException: Invalid operation: result set
KM> kmarsden > ImplicitClose tests complete
KM> kmarsden Test Failed.
KM> kmarsden *** End:   resultset jdk1.4.2_03 DerbyNetClient 2005-06-01 05:17:10 ***
KM> kmarsden that's the output for client
KM> Bogomips_ Sigh...
KM> kmarsden that is good
KM> kmarsden accidentally ran client first
KM> Bogomips_ ok, good. Whew :-)
KM> kmarsden *** Start: resultset jdk1.4.2_03 2005-06-01 05:18:21 ***
KM> kmarsden 1a2,7
KM> kmarsden > Begin ImplicitClose tests
KM> kmarsden > 1
KM> kmarsden > 2
KM> kmarsden > Final call to ResultSet.next()
KM> kmarsden > Call successful
KM> kmarsden > ImplicitClose tests complete
KM> kmarsden Test Failed.
KM> kmarsden and for embedded
KM> Bogomips_ good :-)
KM> kmarsden For embedded looks good except it says it failed
KM> Bogomips_ well, you still have to run ant, correct?
KM> Bogomips_ for the new master file.
KM> kmarsden but I think we just need to update the master
KM> Bogomips_ agreed
KM> kmarsden do you get the same result
KM> kmarsden ?
KM> Bogomips_ Before I modified the master, yes.
KM> kmarsden so now mine passes
KM> kmarsden OK. So lets look a bit at qryclsimp
KM> kmarsden First looking at the specs
KM> kmarsden http://www.opengroup.org/dbiop/
KM> kmarsden There are three specifications.
KM> kmarsden DRDA - Describes the overall flow
KM> kmarsden FD:OCA describes the data type translation for different machines
KM> kmarsden DDM describes the tokens that we send back and forth
KM> kmarsden That is the 10,000 foot overview
KM> kmarsden We are going to look at the DDM Manual C045
KM> Bogomips_ Now to enter the orbit?
KM> Bogomips_ k
KM> kmarsden if you search for qryclsimp
KM> kmarsden You will see I think that is only sent as part of the OPNQRY request.
KM> Bogomips_ Alright
KM> kmarsden looking at page 680 you can see the various values that can be sent
KM> kmarsden 00 - Server choice
KM> Bogomips_ 694 volume 3
KM> kmarsden right. 
KM> kmarsden I think I gave you the page number at the bottom.  
KM> kmarsden 01 - Server has to close
KM> kmarsden 02 - Server should not close
KM> kmarsden the server should ignore the request for scrollable cursors even if 01
KM> kmarsden The server indicates the end of data with SQLState 0200
KM> kmarsden sorry 02000
KM> kmarsden Do you see any more useful information here?
KM> Bogomips_ looking
KM> Bogomips_ If the query is scrollable, the server ignores the QRYCLSIMP value.
KM> Bogomips_ There is also the definition of implicit closing but that is easily understood.
KM> kmarsden yes. So I think that what this tells us is that we need to add a test for
a scrollable cursor fetching past the end.
KM> kmarsden to make sure it doesn't get closed
KM> Bogomips_ Alright. Now to find out how to request a scrollable ResultSet
KM> kmarsden http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Connection.html#prepareStatement(java.lang.String,
int, int)
KM> Bogomips_ I believe the javadocs for java.sql.Connection.createStatement(int resultSetType,
int resultSetConcurrency) tell us.
KM> Bogomips_ also true.
KM> kmarsden I am guessing there are examples in resultset.java
KM> Bogomips_ quite possibly.
KM> kmarsden looking
KM> Bogomips_ There is an example with SCROLL_INSENSITIVE, but I cannot find the reverse.
KM> kmarsden I think that would be fine for this.
KM> kmarsden but we will look at the code and see if there is any special handling for
SCROLL_SENSITIVE and decide if we need two tests
KM> kmarsden For now we can just make a note to add a test while we finish our analysis
KM> kmarsden I put todo tags in chats sometimes.
KM> Bogomips_ Alright. 
KM> Bogomips_ Do you know which of these two options statements default to?
KM> kmarsden TODO:  Write tests fetching past end of scrollable resulsets.
KM> kmarsden hmm.
KM> Bogomips_ "Result sets created using the returned Statement object will by default
be type TYPE_FORWARD_ONLY and have a concurrency level of CONCUR_READ_ONLY."
KM> kmarsden Resultsets default to forward only
KM> kmarsden Then you specifify SCROLL_SENSITIVE or SCROLL_INSENSITIVE explicitly if you
want scrollable.
KM> kmarsden  - The constant indicating the type for a ResultSet object that is scrollable
but generally not sensitive to changes made by others. 
KM> kmarsden  - The constant indicating the type for a ResultSet object that is scrollable
and generally sensitive to changes made by others. 
KM> kmarsden OK.  So you said you think the client sends 01?
KM> Bogomips_ On further analysis, I believe the DerbyNet framework sends 01 and the DerbyNetClient
sends 00.
KM> kmarsden OK.  good.  Then probably what is going to happen with our resultset.java
test is that derbynet is going to keep its current output.
KM> kmarsden Only derbynetclient will change behaviour since it sends SERVER_CHOICE (00)
KM> kmarsden Our changes will be on the server side.
KM> kmarsden Let's look at DRDAStatement.java
KM> Bogomips_ Understood. Beyond petitioning IBM for changes in the db2jcc.jar there is
little we can do for a value of 01.
KM> Bogomips_ You may wish to verify my findings.
KM> kmarsden We will verify. I figure we will change the SERVER_CHOICE  option and see
what the behaviour is #:)
KM> kmarsden As for petitioning IBM, I guess you could petition me since I work for IBM.

KM> kmarsden I will file a bug with JCC and hopefully they will fix.
KM> kmarsden but we will just worry about the server and client for our changes.
KM> Bogomips_ :-) 
KM> Bogomips_ Of importance before we start modifying codepoint values is the small bug
in the setOPNQRYoptions().
KM> kmarsden yes
KM> kmarsden The one thing that strikes me in looking at this is that QRYCLSIMP is only
sent on OPNQRY
KM> kmarsden not on PRPSQLSTT or any other statement related call.
KM> kmarsden I think that it is wrong that it is in DRDAStatement at all
KM> kmarsden If we look  at setOPNQRYoptions it is just updating the DRDAResultSet values.
KM> kmarsden and if we fix the bug you found.  the value in DRDAStatement is not being
used at all I think.
KM> Bogomips_ Quite possibly.
KM> kmarsden If i check references for DRDAStatement.qryclsimp
KM> kmarsden it is only used by setOPNQRYoptions, but in fact shouldn't be used there at
KM> Bogomips_ It is a protected variable so it can be called from other classes in the
package. Is it there for future compatibility?
KM> kmarsden I don't think so. 
KM> Bogomips_ Or should the value always be specific to the DRDAResultSet?
KM> Bogomips_ k
KM> kmarsden It should always be specific to the resultset.
KM> kmarsden I think it is just part of the general messiness of network server.
KM> Bogomips_ Alright. A subsequent issue that might stem from our investigations would
be to clean up DRDAStatement.
KM> kmarsden I think the same will apply to the other options as well.
KM> kmarsden Yes!
KM> Bogomips_ Alright.
KM> Bogomips_ I guess we are out of time, do you have any homework assignments for me :-)
KM> kmarsden Yes.  Search the rest of the DDM Manual and DRDA manual for qryclsimp references
and make sure  we are not missing anything
KM> kmarsden Think about adding a test for scrollable resultsets to our test.
KM> kmarsden get your tests running
KM> kmarsden I guess that last one is the most important.
KM> Bogomips_ Indeed. 
KM> Bogomips_ Do you think we need to test ResultSets from both PreparedStatements and
Statements? If not I can remove that functionality and replace it with Scrollability.
KM> Bogomips_ If we do need both statements, I'll just layer the additional functionality
on top.
KM> kmarsden I think that we don't need both prepared statements and statements since they
wil both go through the same code path
KM> Bogomips_ k
KM> kmarsden The general idea is that our tests optimally will provide 100% code coverage
of the areas we change.
KM> Bogomips_ Since this is an area we will likely not touch it will not be needed. 
KM> Bogomips_ Alright, when would you next like to meet?
KM> kmarsden Hold on. let me check something
KM> kmarsden if we meet 9am my time tomorrow is that too late for you?
KM> Bogomips_ No that should be fine.
KM> kmarsden OK. good. until then.  
KM> Bogomips_ bye
KM> * Bogomips_ (~ca@dyna167-237.acadiau.ca) has left #derby
Dag H. Wanvik
Sun Microsystems, Web Services, Database Technology Group
Haakon VII gt. 7b, N-7485 Trondheim, Norway
Tel: x43496/+47 73842196, Fax:  +47 73842101

NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact
the sender by reply email and destroy all copies of the original

View raw message