Re: Derby 213 patch (was Re: [jira] Updated: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server)

[Philip Wilder <05...@acadiau.ca>]

Kathey Marsden wrote:

>Philip Wilder (JIRA) wrote:
>
>  
>
>>    [ http://issues.apache.org/jira/browse/DERBY-213?page=all ]
>>
>>Philip Wilder updated DERBY-213:
>>--------------------------------
>>
>>   Attachment: Derby213patch_Aug112005.patch
>>
>>An interim patch to bring client in line with embedded. Includes the following changes:
>>- Additional tests in jdbcapi/resultset.java
>> 
>>
>>    
>>
>I got a little lost in the tests, but generally more tests are good.  A
>couple of thoughts..
>
>Maybe your chart that explains the helper array could be expanded to
>cover what is being tested or else have comments in the code or test
>output that makes it clear.
>  
>
I find myself guilty of brevity over clarity. I've managed to reuse code 
for the different tests but it seems at the cost of understanding. I 
guess it is time to bite the bullet and write out a series of tests 
rather then 1 or 2 complicated ones.

>I don't think it is  so good to have  references to internal classes
>(e.g org.apache.derby.client.am.ResultSet) in the functional tests.
>Is there a  way within the public API to test if autocommit has
>occurred, maybe the current XID from the lock table VTI would help.
>  
>
Initial investigations don't yield anything useful from the LockTable. 
It would seem that for the client ResultSet a lock, identical in all 
ways except for the final digit in the XID, is held both before and 
after the auto commit. This differs from the embedded behavior where 
attempting to access the lock table tells me that there are never any 
locks held for my tests. I'll continue investigating but if someone can 
prove me wrong and show how the lock table can be useful in this regard 
or offer me an alternate solution I'd be most appreciative.

>It seemed a  little funny to have the tablename as a static particularly
>at the bottom of the file.
>  
>
Fair enough. It was convenient for use with the procedure call but a 
work around is available

>The DerbyNet canon says FAIL and prints an exception for one test.  I
>think in fact the behavior is different for the driver, so I would think
>it better to either skip the test or print it in the master as expected
>output for that framework.
>  
>
The behavior is different for the JCC driver. My rational was to include 
this in the tests to let people know that JCC was still "broken" in this 
respect but it seems all I did was create confusion. I'll change this.

>>     * Checks to see if an auto-commit should be performed have been moved to Statement to mimic embedded functionality.
>>     * Multiple ResultSets will now auto-commit if all ResultSets are closed if auto-commit is turned on.
>>
>> 
>>
>>    
>>
>Statement.java has an import of  
>org.apache.derby.impl.jdbc.EmbedResultSet which it should not. I don't
>think it is being used.
>  
>
Correct. Both the SQLException and the EmbedResultSet were hold overs 
from a code infusion from EmbedStatement.

>This is my *big* question about the code changes.  It looks like the
>autocommit will only be sent if the result sets are actually closed  not
>if I fetch past the last row of a forward only result set as I think is
>supposed to be the case.  Am I reading this correctly?
>  
>
Kathey and I discussed this via IRC and came to the conclusion that this 
was a miscommunication on my part. If there is 1 ResultSet it will 
always auto-commit on completion. If there are 2 or more ResultSets 
auto-commit will only occurr if all ResultSets but the comitting 
ResultSet are closed. While there is some discussion of whether this is 
the correct approach, I am merely attempting to emulate embedded, not 
make a judgment call as to what behavior is right.

>  
>
>>While the derbyall test suite was run with only one failure (since rectified), there are still a couple of issues worthy of consideration.
>>- Connection.setAutoCommit() java documentation states " In advanced cases, a single statement may return multiple results as well as output parameter values. In these cases, the commit occurs when all results and output parameter values have been retrieved." While my solution auto-commits when all ResultSets have been closed, it does not take into consideration output parameters. However, looking at the embedded implementation it does not look like embedded takes output parameters into consideration either.
>>- The SVN patch tool seems to act very strangely for updatableResultSet.out, deleting then adding lines that were identical. I cannot account for this behavior.
>> 
>>
>>    
>>
>did reverting,  updating  the eol properties correct this problem?
>  
>
It looks like this might do the trick

Philip

Re: Derby 213 patch

[Mike Matrigali <mi...@sbcglobal.net>]

A method that does not require looking at a lock table, it instead
to test directly the behavior of what is locked.  It will require
2 connections (not 2 threads), so very easy to do in java/jdbc.
Something like:
o set serializable
o execute select statement in thread one
o try to update same row in thread 2, if thread one committed then
   update will succeed, if not then lock will time out.
To make test run faster, set default lock timeout to something small
like 1 second.

Be careful about depending on anything about XID's, as they are
implementation specific.  As you have seen they can be reused, they
may jump by more than one depending on timing (background threads
may use xacts also), and they may not change at all for read only
transactions.

Philip Wilder wrote:
>>
>>
>>> I don't think it is  so good to have  references to internal classes
>>> (e.g org.apache.derby.client.am.ResultSet) in the functional tests.
>>> Is there a  way within the public API to test if autocommit has
>>> occurred, maybe the current XID from the lock table VTI would help.
>>>  
>>>
>> Initial investigations don't yield anything useful from the LockTable. 
>> It would seem that for the client ResultSet a lock, identical in all 
>> ways except for the final digit in the XID, is held both before and 
>> after the auto commit. This differs from the embedded behavior where 
>> attempting to access the lock table tells me that there are never any 
>> locks held for my tests. I'll continue investigating but if someone 
>> can prove me wrong and show how the lock table can be useful in this 
>> regard or offer me an alternate solution I'd be most appreciative. 
> 
> 
> 
> Sorry Kathey, I'm being dim. XIDs have the potential to work they just 
> require a little more creativity then my previous solution. Testing 
> seems to indicate that XIDs aren't held over a commit. Ergo if I compare 
> the XID before the commit with any XIDs after the commit and have a 
> match I have criteria for failing the test.
> 
> Philip
> 
> 

Re: Derby 213 patch

[Philip Wilder <05...@acadiau.ca>]

>
>
>> I don't think it is  so good to have  references to internal classes
>> (e.g org.apache.derby.client.am.ResultSet) in the functional tests.
>> Is there a  way within the public API to test if autocommit has
>> occurred, maybe the current XID from the lock table VTI would help.
>>  
>>
> Initial investigations don't yield anything useful from the LockTable. 
> It would seem that for the client ResultSet a lock, identical in all 
> ways except for the final digit in the XID, is held both before and 
> after the auto commit. This differs from the embedded behavior where 
> attempting to access the lock table tells me that there are never any 
> locks held for my tests. I'll continue investigating but if someone 
> can prove me wrong and show how the lock table can be useful in this 
> regard or offer me an alternate solution I'd be most appreciative. 


Sorry Kathey, I'm being dim. XIDs have the potential to work they just 
require a little more creativity then my previous solution. Testing 
seems to indicate that XIDs aren't held over a commit. Ergo if I compare 
the XID before the commit with any XIDs after the commit and have a 
match I have criteria for failing the test.

Philip