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
used.
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:
Hi,
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.
thanks,
-------
mehran
