Lock granularity

Derby can be configured for table-level locking. With table-level locking, when a transaction locks data in order to prevent any transaction anomalies, it always locks the entire table, not just those rows being accessed.

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.

You typically set lock granularity for the entire Derby system, not for a particular application. However, at runtime, Derby may escalate the lock granularity for a particular transaction from row-level locking to table-level locking for performance reasons. You have some control over the threshold at which this occurs. For information on turning off row-level locking, see "derby.storage.rowLocking" in the Java DB Reference Manual. For more information about automatic lock escalation, see "About the system's selection of lock granularity" and "Transaction-based lock escalation" in Tuning Java DB. For more information on tuning your Derby system, see "Tuning databases and applications," also in Tuning Java DB.

Related concepts
Isolation levels and concurrency
Configuring isolation levels
Types and scope of locks in Derby systems