Egidijus Vaisnora <[email protected]> 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
>
