Search code examples
databasederby

Does database operation of writing can be blocked by operation of reading?


We have a problem with database derby. Sometimes operation of writing takes many time. Is possible that many operations of reading blocking writing? Thanks.


Solution

  • Reads require a shared lock. Writes (updates) require an exclusive lock. To get an exclusive lock, a transaction has to wait for shared locks to be released. So a reader can block a writer.

    Another transaction that tries to read the same data is permitted to read, but a transaction that tries to update the data will be prevented from doing so until the shared lock is released.

    Also see Derby's Type and Scope of Locks.

    You might be able to reduce the impact by changing the isolation level of one or more transactions. Derby's default is READ COMMITTED, which means you'd have to set one or more of the readers to READ UNCOMMITTED to improve concurrency. But READ UNCOMMITTED allows dirty reads, nonrepeatable reads, and phantom reads. (READ COMMITTED allows nonrepeatable reads and phantom reads, but doesn't allow dirty reads.)

    Another way to reduce readers blocking writers is to make the readers run faster. Tune your queries by reading the query execution plan, by using both single- and multi-column indexes wisely, and by periodically rebuilding the indexes to reduce fragmentation.