Monitoring deadlocks

The derby.stream.error.logSeverityLevel property determines the level of error that you are informed about.

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.

Note: 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 how to set properties, and information about the specific properties that are mentioned in this topic, see Tuning Java DB.

Here is an example of an error message when Derby 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

Note: You can use the derby.locks.waitTimeout and derby.locks.deadlockTimeout properties to configure how long Derby 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 Derby application behavior in the Java DB Developer's Guide.