background image
<< Creating a log in a non-default location | Reclaiming unused space >>

Obtaining locking information

<< Creating a log in a non-default location | Reclaiming unused space >>
Derby Server and Administration Guide
84
When the log is not in the default location, backing up and restoring a database can
require extra steps. See
Backing up and restoring databases
for details.
Obtaining locking information
Derby provides a tool to monitor and display locking information. This tool can help you
create applications that minimize deadlock. It can also help you locate the cause of
deadlock when it does occur.
To diagnose locking problems, constantly monitor locking traffic by logging all deadlocks
by using the derby.locks.monitor property.
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 working with properties, see the Derby Developer's Guide. For
information about the specific properties that are mentioned in this topic, see the Derby
Reference Manual
.
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 Derby Developer's Guide.