db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: table locking
Date Tue, 22 Nov 2005 23:07:40 GMT
I guess that table is a little confusing.  It is not saying that
table level locking is the default when autocommit is off.  It is
saying that IF you use serializable and/or table level locking then
you will get less concurrency if you don't use autocommit.  There
is a way to force table level locking but it is not the default in
any case.

By default derby applications use row level locking and read committed
isolation level whether you have autocommit set to true or false.

Note even in serializable the only table level lock if you are accessing
tables without indexes.  If there are indexes then row locks are still

Mehran Sowdaey wrote:
> Please see:
> <http://db.apache.org/derby/docs/10.0/manuals/develop/develop63.html>
> (Table 2). This is a 10.0 document but we have seen the same in 10.1
> thanks,
> -------
> mehran
> Mike Matrigali wrote On 11/22/05 11:24,:
>>Derby uses row locking by default, can you please explain why you
>>think it is table locking.  Derby does get table level intent locks,
>>to enable the row locking feature - so for instances when updating
>>a row in a table you will get a table level IX and a row level X, but
>>another transaction will also be able to get a table level IX and a
>>row level X lock on another row.
>>There are situations depending on isolation level and lock escalation
>>where real table level locks are requested, not sure if you are running
>>into that.  More information is needed.
>>Mehran Sowdaey wrote:
>>>When running derby in server mode if autocommit is turned off table
>>>locking occurs. Is there anyway to prevent that and have row level
>>>locking. We have tried changing a few of derby parameters without success.

View raw message