Lock granularity 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. Lock granularityLockingtable-levelrow-level

By default, 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 system, not for a particular application. However, at runtime, 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 . For more information about automatic lock escalation, see "About the system's selection of lock granularity" and "Transaction-based lock escalation" in . For more information on tuning your system, see "Tuning databases and applications," also in .