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 "Controlling
application behavior"
in the .