users@glassfish.java.net

Re: Problem EJB Timer Service: A lock could not be obtained within the time

From: <glassfish_at_javadesktop.org>
Date: Fri, 10 Oct 2008 06:23:12 PDT

Thanks a lot, I've activated derby-lock-print.

I'm using this to settings:
derby.locks.deadlockTrace=true
derby.locks.monitor=true

Accordint to table/row lock:

Changing the lock granularity for the table
The LOCKSIZE clause allows you to override row-level locking for the specific table,
if your system uses the default setting of row-level locking. (If your system is set for
table-level locking, you cannot change the locking granularity to row-level locking,
although Derby allows you to use the LOCKSIZE clause in such a situation without
throwing an exception.) To override row-level locking for the specific table, set locking
for the table to TABLE. If you created the table with table-level locking granularity, you
can change locking back to ROW with the LOCKSIZE clause in the ALTER TABLE
STATEMENT. For information about why this is sometimes useful, see Tuning Java DB.

Links:
 * http://db.apache.org/derby/docs/dev/devguide/cdevconcepts15366.html
 * http://db.apache.org/derby/docs/dev/devguide/cdevconcepts23810.html

Derby:

By default, Derby is configured for row-level locking. Row-level locking uses more memory but allows greater concurrency, which works better in multi-user systems. Table-level locking works best with single-user applications or read-only applications.
[Message sent by forum member 'hegalor' (hegalor)]

http://forums.java.net/jive/thread.jspa?messageID=304513