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 Tuning Derby. For more information about automatic lock escalation, see "About the System's Selection of Lock Granularity" and "Transaction-Based Lock Escalation" in Tuning Derby. For more information on tuning your Derby system, see "Tuning Databases and Applications".