Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Tue, 31 Oct 2017 15:06:00 +0000 (UTC)
From: "Brett Bergquist (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <JIRA.13113208.1509412667000.111987.1509462360250@Atlassian.JIRA>
In-Reply-To: <JIRA.13113208.1509412667000@Atlassian.JIRA>
References: <JIRA.13113208.1509412667000@Atlassian.JIRA> <JIRA.13113208.1509412667965@jira-lw-us.apache.org>
Subject: [jira] [Commented] (DERBY-6975) Bug in
 SequenceUpdater.getCurrentValueAndAdvance - break used instead of continue
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Tue, 31 Oct 2017 15:06:05 -0000


    [ https://issues.apache.org/jira/browse/DERBY-6975?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1622=
6948#comment-16226948 ]=20

Brett Bergquist commented on DERBY-6975:
----------------------------------------

I thought this was the same issue that I was seeing earlier last month but =
I see it is slightly different so I removed my comment but I will still rev=
iew this code and proposed fix.

> Bug in SequenceUpdater.getCurrentValueAndAdvance - break used instead of =
continue
> -------------------------------------------------------------------------=
--------
>
>                 Key: DERBY-6975
>                 URL: https://issues.apache.org/jira/browse/DERBY-6975
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.14.1.0
>            Reporter: David Sitsky
>         Attachments: fix.patch
>
>
> I have an application that sporadically gets this exception when insertin=
g a lot of rows using a sequence generator.
> {noformat}
> Caused by: ERROR 40XL1: A lock could not be obtained within the time requ=
ested=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 at org.apache.derby.iapi.error=
.StandardException.newException(StandardException.java)=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 at org.apache.derby.iapi.error=
.StandardException.newException(StandardException.java)=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 at org.apache.derby.impl.sql.c=
atalog.SequenceUpdater.tooMuchContentionException(SequenceUpdater.java)=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 at org.apache.derby.impl.sql.c=
atalog.SequenceUpdater.getCurrentValueAndAdvance(SequenceUpdater.java)=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 at org.apache.derby.impl.sql.c=
atalog.DataDictionaryImpl.getCurrentValueAndAdvance(DataDictionaryImpl.java=
)=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 at org.apache.derby.impl.sql.e=
xecute.BaseActivation.getCurrentValueAndAdvance(BaseActivation.java)=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 at org.apache.derby.impl.sql.e=
xecute.InsertResultSet.getSetAutoincrementValue(InsertResultSet.java)=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 at org.apache.derby.impl.sql.e=
xecute.BaseActivation.getSetAutoincrementValue(BaseActivation.java)=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 at org.apache.derby.exe.ac5607=
40aax015fx6bc1x68cax000002339e626a.e0(ac560740aax015fx6bc1x68cax000002339e6=
26a.java)=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 at org.apache.derby.impl.servi=
ces.reflect.DirectCall.invoke(DirectCall.java)=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 at org.apache.derby.impl.sql.e=
xecute.RowResultSet.getNextRowCore(RowResultSet.java)=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 at org.apache.derby.impl.sql.e=
xecute.NormalizeResultSet.getNextRowCore(NormalizeResultSet.java)=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 at org.apache.derby.impl.sql.e=
xecute.DMLWriteResultSet.getNextRowCore(DMLWriteResultSet.java)=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 at org.apache.derby.impl.sql.e=
xecute.InsertResultSet.getNextRowCore(InsertResultSet.java)=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 at org.apache.derby.impl.sql.e=
xecute.InsertResultSet.open(InsertResultSet.java)=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 at org.apache.derby.impl.sql.G=
enericPreparedStatement.executeStmt(GenericPreparedStatement.java)=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 at org.apache.derby.impl.sql.G=
enericPreparedStatement.execute(GenericPreparedStatement.java)=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ... 25 more=20
> {noformat}
> When I look at the code in question, it comes down to this method:
> {code}
>     /**
>      * <p>
>      * Get the next sequence number managed by this generator and advance=
 the number. Could raise an
>      * exception if the legal range is exhausted and wrap-around is not a=
llowed.
>      * Only one thread at a time is allowed through here. We do not want =
a race between the
>      * two calls to the sequence generator: getCurrentValueAndAdvance() a=
nd allocateNewRange().
>      * </p>
>      *
>      * @param returnValue This value is stuffed with the new sequence num=
ber.
>      */
>     public synchronized void getCurrentValueAndAdvance
>         ( NumberDataValue returnValue ) throws StandardException
>     {
>         //
>         // We may have to try to get a value from the Sequence Generator =
twice.
>         // The first attempt may fail because we need to pre-allocate a n=
ew chunk
>         // of values.
>         //
>         for ( int i =3D 0; i < 2; i++ )
>         {
>             //
>             // We try to get a sequence number. The SequenceGenerator met=
hod is synchronized
>             // so only one writer should be in there at a time. Lock cont=
ention is possible if
>             // someone has selected from SYSSEQUENCES contrary to our adv=
ice. In that case,
>             // we raise a TOO MUCH CONTENTION exception.
>             //
>             long[] cvaa =3D _sequenceGenerator.getCurrentValueAndAdvance(=
);
>            =20
>             int status =3D (int) cvaa[ SequenceGenerator.CVAA_STATUS ];
>             long currentValue =3D cvaa[ SequenceGenerator.CVAA_CURRENT_VA=
LUE ];
>             long lastAllocatedValue =3D cvaa[ SequenceGenerator.CVAA_LAST=
_ALLOCATED_VALUE ];
>             long numberOfValuesAllocated =3D cvaa[ SequenceGenerator.CVAA=
_NUMBER_OF_VALUES_ALLOCATED ];
>            =20
>             switch ( status )
>             {
>             case SequenceGenerator.RET_OK:
>                 returnValue.setValue( currentValue );
>                 return;
>                =20
>             case SequenceGenerator.RET_MARK_EXHAUSTED:
>                 updateCurrentValueOnDisk( currentValue, null );
>                 returnValue.setValue( currentValue );
>                 return;
>                =20
>             case SequenceGenerator.RET_ALLOCATE_NEW_VALUES:
>                =20
>                 if ( updateCurrentValueOnDisk( currentValue, lastAllocate=
dValue ) )
>                 {
>                     _sequenceGenerator.allocateNewRange( currentValue, nu=
mberOfValuesAllocated );
>                 }
>                 break;
>            =20
>             default:
>                 throw unimplementedFeature();
>             }
>         }
>         //
>         // If we get here, then we failed to allocate a new sequence numb=
er range.
>         //
>         throw tooMuchContentionException();
>     }
> {code}
> If I understand the intent of this code, in the SequenceGenerator.RET_ALL=
OCATE_NEW_VALUES case, we allocate a new sequence generator range and then =
we are meant to re-execute the loop again to use it, however since "break" =
is used we break out of the for loop and throw the exception.
> It seems if we replace "break" with 'continue" this will work as expected=
?


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)