Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <461EC7B4.8000408@sbcglobal.net>
Date: Thu, 12 Apr 2007 16:58:44 -0700
From: Mike Matrigali <mikem_app@sbcglobal.net>
Reply-To: mikem_app@sbcglobal.net
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: Question about UpdateCursorTest.testVirtualMemoryHeap
References: <461EB325.1030004@amberpoint.com> <461EC44E.3000907@sbcglobal.net>
In-Reply-To: <461EC44E.3000907@sbcglobal.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Mike Matrigali wrote:

> 
>> I'm a bit confused about the test program
>> UpdateCursorTest.testVirtualMemoryHeap. This test program
>> appears to depend on the order of the rows returned, but
>> it does not contain an ORDER BY clause in the query. Here's
>> the code I'm looking at, from UpdateCursorTest.java:
>>
>>     /**
>>      * Test the virtual memory heap.
>>      *
>>      * @throws SQLException
>>      */
>>     public void testVirtualMemoryHeap() throws SQLException {
>>         PreparedStatement select = prepareStatement("select c1, c3 
>> from t1 where c3 > 1 and c1 > 0 for update");
>>         Statement update = createStatement();
>>         String cursorName;
>>         ResultSet cursor;
>>         int expectedValue = 1;
>>
>>         cursor = select.executeQuery(); // cursor is now open
>>         cursorName = cursor.getCursorName();
>>
>>         /* scan the entire table except the last row. */
>>         for (int i = 0; i < SIZE_OF_T1 - 1; i++) {
>>
>>             /*  Notice the order in the rows we get: from 2 to 102 asc 
>> order on second column (c3)
>>              *  then from 202 down to 103 on that column; then from 
>> 203 up to 250.  The reason is
>>              *  we are using asc index on c3, all the rows updated are 
>> in the future direction of the
>>              *  index scan, so they all get filled into a hash table.  
>> The MAX_MEMORY_PER_TABLE
>>              *  property determines max cap of hash table 100.  So 
>> from row 103 it goes into virtual
>>              *  memory heap, whose in memory part is also 100 
>> entries.  So row 103 to 202 goes into
>>              *  the in-memory part and gets dumped out in reverse 
>> order.  Finally Row 203 to 250"
>>              *  goes into file system.  Here we mean row ids.
>>              */

I have not looked at test code or derby code, but the comments do seem
worrysome.  Picking a specific plan can be dependent on machine speed,
amount of memory at the particular time the test is run (so very easily
could change as more tests are added to suite).  Also the comments talk
about expecting a particular order when scanning a hash table - I know
that I have seen different order of rows coming out of java hash tables
depending on what JVM you are using.

I have filed DERBY-2543 to track the new regression suite bug.
>>
>> This test seems to be very sensitive to the precise query execution
>> strategy that is being used, but I don't see how the test is
>> controlling that query execution strategy.
>>
>> Can somebody clarify how the test works for me?
>>
>> thanks,
>>
>> bryan
>>
>> P.S. The reason that I'm asking is that my proposed change for
>> DERBY-2526 causes this test to fail, but I'm not sure whether that
>> means my change is bad, or whether this test is depending on a
>> query execution strategy that is not guaranteed to occur.
>>
>>
>>
> 
> 
>