if these are really unsigned longs and we actually need a  < comparison then I dont think starting with LONG.MIN will help.... I really think looking at the 4 cases for mapping unsigned longs into longs will work better.

david jencks

On Jan 22, 2008, at 4:49 PM, Alex Karasulu wrote:

Hi Emmanuel,

On Jan 22, 2008 7:24 PM, Emmanuel Lecharny <elecharny@gmail.com> wrote:
Hi guys,

yesturday and today, I fight against a vicious bug for hours. Thanks to
Pierre-Arnaud and Alex, I found the reason for the failures I was

I empathize with your pain.  BTW I did very little to help.

However after reading your post I considered just the high level picture and here's what I thought:

(1) these longs are ids to identify uniquely each entry in a BTree based backend
(2) the master table contains a durable sequence which is used to generate these values and it presently starts the sequence at 1
(3) JDBM or other BTrees don't care if the Long ID is positive or negative as long as it is unique for each entry in the partition's master table
(4) When you do comparisons with subtraction (x - y) to see if something is greater than 0 or not in a comparator you don't know if x is bigger or smaller so you cannot determine if overflows will result.

You might be able to fix this in two ways.  First you can fix the comparator to consider buffer overflow and just not use subtraction.  You can just check if one Long is bigger than another and return 0, -1, or 1 based on the comparisons.  I guess both these mechanisms work.

Another thing to consider out side of fixing the comparator is to start the sequence at LONG_MIN instead of zero.

What happened is that the Key used to extract an entry from the master
table was compared with the stored Keys using a compare() method which
uses long, doing some simple if ( key1 > key2 ) then ... test.

This is obviously wrong if we are working with unsigned longs, because
Java does not treat longs as unsigned, so -1 is always > to any positive
value (because the upper bit is 1 for negative values), but java >
operator does not take this bit into account.

After a convo with David Jencks, we agreed that we need a four steps
comparison :

if ( x >= 0 and y >=  0) then return x > Y
if ( x < 0 and y >= 0) then return x
if ( x >= 0 and y < 0) then return y
if ( x < 0 and y < 0) then return -x < -y

I thought for the Comparator you have to return 0, -1, 1.