How to write BTree entries to distinct pages

Question

Hi All,
I am writing concurrent transaction tests for my Java Library that uses a Berkeley-DB BTree. The intention of these tests are to assert that my library provide the advertised levels of isolation by using the underlying Berkeley locking correctly. Here is a simple example test:
--- Java ---
String setup = "setup: declare(X,Y,Z) ";
String writeY = "writeY: temp=X Y=1 write|commit";
String writeZ = "writeZ: temp=X Z=1 write|commit";
new ScenarioRunner(setup, writeY, writeZ).run();
In this test, I am simply checking that no conflicts occurred (shared reads, non-overlapping writes). However, to make the test work, I need to make sure that I create entries (X,Y,Z) on separate pages.
So how does one accomplish this?
My current (painful) solution to is create a set of test values and then select those values that appear on different pages to be used as X,Y,Z in the test. This is accomplished by reading the logs (using db4.6_printlog).
Your Ideas?
Thanks in Advance,
Roberto
Edited by: Roberto Faria on Apr 20, 2009 2:59 PM

Answer 1

Hi Roberto,
Just in case you are still in the look for a way to resolve.
Suppose that you have the database page size set to 512B. The size of an item (key or data item) that can be stored onto a leaf page will be approximately 128B (usually calculated as page_size/4). Any item exceeding this size will be forced onto an overflow page.
[http://www.oracle.com/technology/documentation/berkeley-db/db/ref/am_conf/pagesize.html|http://www.oracle.com/technology/documentation/berkeley-db/db/ref/am_conf/pagesize.html]
[http://www.oracle.com/technology/documentation/berkeley-db/db/ref/am_misc/diskspace.html|http://www.oracle.com/technology/documentation/berkeley-db/db/ref/am_misc/diskspace.html]
The actual formula for calculating the size of an overflow item looks like this: overflow_item_size = (page_size - page_overhead) / minimum_no_of_keys * 2 - item_overhead * 2
Remember that on a Btree database page the minimum number of keys that can be stored is 2 (each record requires 2 slots, one for the key, one for the data).
Now, you can pad your key and data items so that they extend up to this limit. You can set your page size to a 512B, pad the items so that they extend up to 111B (based on the formula mentioned above) and store the records you need but with some dummy records in between, such as (key | data):
keyX<pad_bytes> | dataForKeyX<pad_bytes>
keyXX<pad_bytes> | dataForKeyXX<pad_bytes> (dummy record)
keyZ<pad_bytes> | dataForKeyZ<pad_bytes>
keyZZ<pad_bytes> | dataForKeyZZ<pad_bytes> (dummy record)
The idea is that considering that by default a lexicographical comparison routine is used by BDB for key comparison, each record you need will be distributed onto a page with an ignorable/dummy record, hence you should end up with the keys you need on different leaf pages.
You'll have to adjust the number of padding bytes according to the page size and the size of your key/data items.
Regards,
Andrei