db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew McIntyre" <mcintyr...@gmail.com>
Subject Re: Question about UpdateCursorTest.testVirtualMemoryHeap
Date Fri, 13 Apr 2007 00:03:02 GMT
On 4/12/07, Bryan Pendleton <bpendleton@amberpoint.com> wrote:
>
> 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?

Perhaps this comment from the original (pre-JUnit) test should have
been kept as well:

  Not done in ij since we need to do many "next" and "update" to be
  able to excercise the code of creating temp conglomerate for virtual
  memory heap.  We need at minimum
  200 rows in table, if "maxMemoryPerTable" property is set to 1 (KB).
  This includes 100 rows to fill the hash table and another 100 rows
  to fill the in-memory heap.

So the size of the rows for t1 cause the hashtable to fill after 100
rows, the in-memory heap  after another 100, and then finally a few
more rows to go to the backing store. It appears to depend on the
behavior of the in-memory heap of reversing the order of the rows that
are put into it. I'm not entirely sure what the 'in-memory heap' here
is referring to, presumably this is the in-memory portion of a
BackingStoreHashtable?

As Mike pointed out, this test has been failing in the nightlies, so
it might not be your change that is causing the failure. Also
unfortunate is the fact that I can't reproduce this on my machine,
although I am working on that. The check for row order was added
because from the comments in the previous test, it was clear that the
row order was what was intended to be checked.

andrew

Mime
View raw message