By default, derby.stream.error.logSeverityLevel is
set to 40000. If derby.stream.error.logSeverityLevel is
set to display transaction-level errors (that is, if it is set to a value
less than 40000), deadlock errors are logged to the derby.log file.
If it is set to a value of 40000 or higher, deadlock errors are not logged
to the derby.log file.
The derby.locks.monitor property ensures that deadlock errors are
logged regardless of the value of derby.stream.error.logSeverityLevel.
When derby.locks.monitor is set to true, all
locks that are involved in deadlocks are written to derby.log along with a unique
number that identifies the lock.
To see a thread's stack trace when a lock is requested, set derby.locks.deadlockTrace to
true. This property is ignored if derby.locks.monitor is
set to false.
Use derby.locks.deadlockTrace with care. Setting this property
can alter the timing of the application, severely affect performance, and
produce a very large derby.log file.
For information about working with properties, see the
. For information about the
specific properties that are mentioned in this topic, see the
.
Here is an example of an error message when aborts
a transaction because of a deadlock:
--SQLException Caught--
SQLState: 40001 =
Error Code: 30000
Message: A lock could not be obtained due to a deadlock,
cycle of locks and waiters is: Lock : ROW, DEPARTMENT, (1,14)
Waiting XID : {752, X} , APP, update department set location='Boise'
where deptno='E21'
Granted XID : {758, X} Lock : ROW, EMPLOYEE, (2,8)
Waiting XID : {758, U} , APP, update employee set bonus=150 where salary=23840
Granted XID : {752, X} The selected victim is XID : 752
You can use the derby.locks.waitTimeout and
derby.locks.deadlockTimeout properties
to configure how long waits
for a lock to be released, or when to begin deadlock checking. For more information
about these properties, see the section that discusses controlling application
behavior in the .