db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: [jira] Updated: (DERBY-4080) Possible deadlock between locks and latches in BTreeController.compareRowsForInsert()
Date Thu, 05 Mar 2009 12:51:25 GMT
Mike Matrigali <mikem_app@sbcglobal.net> writes:

> You seem to have found a number of problems with the new code that
> tries to implement the unique constraint with multiple nulls.  I
> definitely missed the deleted row case when reviewing that code, and
> had assumed it
> just ever needed to search one row left and right.
> I am now wondering if it would be better to make this code work the same
> as the existing code in the regular unique case.  That code makes sure
> there is always only ONE row with the given key (not including the row
> id).  It manipulates the search params so that either that exact row
> is found or it positions in the right place to do the insert.
> It does have some tricky code for when it finds a matching row,
> especially if it is marked deleted, but that code has been working for
> a long time now.

(By the way, do you think this tricky code may be the cause of
DERBY-4032? There we have one deleted row hiding another row with the
same key in a unique index.)

> The approach would be something like:
> o If there is a null in the key then just do the insert normally into
> the non-unique table, using all keys.
> o If no null, then need to change the search params to only use leading
> columns and to not allow exact match - this means changing the
> existing code which would use the
> tables information which would say to use all columns.
> o and then if match use the existing code for unique tables in this case.
> Let me know what you think.  Is this a better approach or should we
> patch up the new code?  Are you interested in doing this?  If not I
> may have time to do this.

Your suggestion sounds like a more robust approach than the current one
to me. I only planned to fix DERBY-4028 and DERBY-4081 for 10.5, as they
seem to be rather easy to fix. So if you have time, feel free to pick
this up. Are you aiming for 10.5? If so, I should probably not check in
the fixes that I have posted. Otherwise, I could check them in now so
that we improve the situation for 10.5 too.

Knut Anders

View raw message