You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by "Dag H. Wanvik" <Da...@Sun.COM> on 2009/07/02 19:25:00 UTC
Re: Derby bug?
Egidijus Vaisnora <eg...@nomagic.com> writes:
> Hello for All,
>
> Questions first:
>
> Deadlock between system tables - is it Derby bug?
> Is it possible to avoid deadlock by configuring derby DB, let say changing lock granularity?
>
> Issue:
>
> I am using 3d part library which makes all transactions with Derby and
> in one single situation (unfortunately not reproducible) I got error
> printing in log about deadlock. It could be 3d part library problem,
> however from the log it obvious that deadlock appeared on Derby system
> tables (they are managed by Derby itself), therefore, I think, it is
> related to Derby code, which doesn't synchronize two transactions
> accessing system tables. Here is log:
The SELECT transaction tries to select from a table (core_File) before
the DLL transaction creating that table has committed..
But you are right, it looks like a Derby DDL dead-lock issue.
Are your connections using auto-commit or not?
Dag
PS! The normal place for such discussion is the derby-user mailing
list, so I am moving it over there.
>
> Lock : TABLE, SYSCOLUMNS, Tablelock
> Waiting XID : {9404, IS} , APP, SELECT cdo_version, cdo_created,
> cdo_revised, cdo_resource, cdo_container, cdo_feature, name, id FROM
> core_File WHERE cdo_id= ? AND (cdo_revised = 0 )
> Granted XID : {7351, IX}
> Lock : ROW, SYSTABLES, (2,14)
> Waiting XID : {7351, X} , APP, CREATE TABLE core_File (cdo_id BIGINT
> NOT NULL, cdo_version INTEGER NOT NULL, cdo_class BIGINT NOT NULL,
> cdo_created BIGINT NOT NULL, cdo_revised BIGINT NOT NULL, cdo_resource
> BIGINT NOT NULL, cdo_container BIGINT NOT NULL, cdo_feature INTEGER
> NOT NULL, name VARCHAR(32672), id VARCHAR(32672))
> Granted XID : {9404, S}
> . The selected victim is XID : 9404.
>
> Thanks,
> --
> Egidijus
>
Re: Derby bug?
Posted by Egidijus Vaisnora <eg...@nomagic.com>.
> Are your connections using auto-commit or not?
Not auto-commit
--
Egidijus
Dag H. Wanvik wrote:
> Egidijus Vaisnora <eg...@nomagic.com> writes:
>
>> Hello for All,
>>
>> Questions first:
>>
>> Deadlock between system tables - is it Derby bug?
>> Is it possible to avoid deadlock by configuring derby DB, let say changing lock granularity?
>>
>> Issue:
>>
>> I am using 3d part library which makes all transactions with Derby and
>> in one single situation (unfortunately not reproducible) I got error
>> printing in log about deadlock. It could be 3d part library problem,
>> however from the log it obvious that deadlock appeared on Derby system
>> tables (they are managed by Derby itself), therefore, I think, it is
>> related to Derby code, which doesn't synchronize two transactions
>> accessing system tables. Here is log:
>
> The SELECT transaction tries to select from a table (core_File) before
> the DLL transaction creating that table has committed..
>
> But you are right, it looks like a Derby DDL dead-lock issue.
> Are your connections using auto-commit or not?
>
> Dag
>
> PS! The normal place for such discussion is the derby-user mailing
> list, so I am moving it over there.
>
>> Lock : TABLE, SYSCOLUMNS, Tablelock
>> Waiting XID : {9404, IS} , APP, SELECT cdo_version, cdo_created,
>> cdo_revised, cdo_resource, cdo_container, cdo_feature, name, id FROM
>> core_File WHERE cdo_id= ? AND (cdo_revised = 0 )
>> Granted XID : {7351, IX}
>> Lock : ROW, SYSTABLES, (2,14)
>> Waiting XID : {7351, X} , APP, CREATE TABLE core_File (cdo_id BIGINT
>> NOT NULL, cdo_version INTEGER NOT NULL, cdo_class BIGINT NOT NULL,
>> cdo_created BIGINT NOT NULL, cdo_revised BIGINT NOT NULL, cdo_resource
>> BIGINT NOT NULL, cdo_container BIGINT NOT NULL, cdo_feature INTEGER
>> NOT NULL, name VARCHAR(32672), id VARCHAR(32672))
>> Granted XID : {9404, S}
>> . The selected victim is XID : 9404.
>>
>> Thanks,
>> --
>> Egidijus
>>
>
Re: Derby bug?
Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
Egidijus Vaisnora <eg...@nomagic.com> writes:
> Dag, do I need to fill bug for this issue?
Please feel free to create a bug report. If you are able to create a
reproduction, that would significantly increase your chances of seeing
it fixed :)
Dag
Re: Derby bug?
Posted by Egidijus Vaisnora <eg...@nomagic.com>.
Dag, do I need to fill bug for this issue?
--
Egidijus
Dag H. Wanvik wrote:
> Egidijus Vaisnora <eg...@nomagic.com> writes:
>
>> Hello for All,
>>
>> Questions first:
>>
>> Deadlock between system tables - is it Derby bug?
>> Is it possible to avoid deadlock by configuring derby DB, let say changing lock granularity?
>>
>> Issue:
>>
>> I am using 3d part library which makes all transactions with Derby and
>> in one single situation (unfortunately not reproducible) I got error
>> printing in log about deadlock. It could be 3d part library problem,
>> however from the log it obvious that deadlock appeared on Derby system
>> tables (they are managed by Derby itself), therefore, I think, it is
>> related to Derby code, which doesn't synchronize two transactions
>> accessing system tables. Here is log:
>
> The SELECT transaction tries to select from a table (core_File) before
> the DLL transaction creating that table has committed..
>
> But you are right, it looks like a Derby DDL dead-lock issue.
> Are your connections using auto-commit or not?
>
> Dag
>
> PS! The normal place for such discussion is the derby-user mailing
> list, so I am moving it over there.
>
>> Lock : TABLE, SYSCOLUMNS, Tablelock
>> Waiting XID : {9404, IS} , APP, SELECT cdo_version, cdo_created,
>> cdo_revised, cdo_resource, cdo_container, cdo_feature, name, id FROM
>> core_File WHERE cdo_id= ? AND (cdo_revised = 0 )
>> Granted XID : {7351, IX}
>> Lock : ROW, SYSTABLES, (2,14)
>> Waiting XID : {7351, X} , APP, CREATE TABLE core_File (cdo_id BIGINT
>> NOT NULL, cdo_version INTEGER NOT NULL, cdo_class BIGINT NOT NULL,
>> cdo_created BIGINT NOT NULL, cdo_revised BIGINT NOT NULL, cdo_resource
>> BIGINT NOT NULL, cdo_container BIGINT NOT NULL, cdo_feature INTEGER
>> NOT NULL, name VARCHAR(32672), id VARCHAR(32672))
>> Granted XID : {9404, S}
>> . The selected victim is XID : 9404.
>>
>> Thanks,
>> --
>> Egidijus
>>
>
Re: Derby bug?
Posted by Egidijus Vaisnora <eg...@nomagic.com>.
Dag, do I need to fill bug report for this issue?
--
Egidijus
Dag H. Wanvik wrote:
> Egidijus Vaisnora <eg...@nomagic.com> writes:
>
>> Hello for All,
>>
>> Questions first:
>>
>> Deadlock between system tables - is it Derby bug?
>> Is it possible to avoid deadlock by configuring derby DB, let say changing lock granularity?
>>
>> Issue:
>>
>> I am using 3d part library which makes all transactions with Derby and
>> in one single situation (unfortunately not reproducible) I got error
>> printing in log about deadlock. It could be 3d part library problem,
>> however from the log it obvious that deadlock appeared on Derby system
>> tables (they are managed by Derby itself), therefore, I think, it is
>> related to Derby code, which doesn't synchronize two transactions
>> accessing system tables. Here is log:
>
> The SELECT transaction tries to select from a table (core_File) before
> the DLL transaction creating that table has committed..
>
> But you are right, it looks like a Derby DDL dead-lock issue.
> Are your connections using auto-commit or not?
>
> Dag
>
> PS! The normal place for such discussion is the derby-user mailing
> list, so I am moving it over there.
>
>> Lock : TABLE, SYSCOLUMNS, Tablelock
>> Waiting XID : {9404, IS} , APP, SELECT cdo_version, cdo_created,
>> cdo_revised, cdo_resource, cdo_container, cdo_feature, name, id FROM
>> core_File WHERE cdo_id= ? AND (cdo_revised = 0 )
>> Granted XID : {7351, IX}
>> Lock : ROW, SYSTABLES, (2,14)
>> Waiting XID : {7351, X} , APP, CREATE TABLE core_File (cdo_id BIGINT
>> NOT NULL, cdo_version INTEGER NOT NULL, cdo_class BIGINT NOT NULL,
>> cdo_created BIGINT NOT NULL, cdo_revised BIGINT NOT NULL, cdo_resource
>> BIGINT NOT NULL, cdo_container BIGINT NOT NULL, cdo_feature INTEGER
>> NOT NULL, name VARCHAR(32672), id VARCHAR(32672))
>> Granted XID : {9404, S}
>> . The selected victim is XID : 9404.
>>
>> Thanks,
>> --
>> Egidijus
>>
>