locking problem when selecting data

["Kasper, Kay" <ka...@ckc.de>]

Hi,

i have a problem with the locking of a row. the situation:

Derby (10.1.3.1 and 10.2.6.1) running as server with two separatly running
client-applications (ij and own application).

Within my application i create a row in the database and commit.
With ij i change the row (only the one column for versioning, not primary
key) in the database and commit.
Within my application i try to update the row with the old version info, the
row is not found and updated. No commit/rollback yet.
Within my application i try to read the row without version condition, only
by primary key and not for update.

Then i get an SQLException (row could not be locked), saying, that not lock
could be set within the definied time.

I ran my application in debug mode to do the ij task between my own
statements.

There was another posting at 04/18/2007 "commit then read immediately" which
sounds very simular.

I'm not using any caching in my application.

On other databases like Orcale and hqsl i don't have that problem. Whats
wrong with the row locking? Why does a normal select try to set a lock?

Thanks for your help.

Kay



--------------------------
ckc ag
Sitz:
Industriestr. 10
38110 Braunschweig

Telefon 05307 / 80 20 0
Telefax 05307 / 80 20 444
http://www.ckc.de

Amtsgericht Braunschweig
HRB 5405

Vorstand:
H.-G. Christian Krentel
(Vorsitzender)

Aufsichtsrat:
Dr. Heinz-Werner Weinrich
(Vorsitzender)
Hans Bodenstein
Dr. Rita Schulz
--------------------------

Re: locking problem when selecting data

[Stanley Bradbury <St...@gmail.com>]

Kasper, Kay wrote:
> Hi,
>
> i have a problem with the locking of a row. the situation:
>
> Derby (10.1.3.1 and 10.2.6.1) running as server with two separatly running
> client-applications (ij and own application).
>
> Within my application i create a row in the database and commit.
> With ij i change the row (only the one column for versioning, not primary
> key) in the database and commit.
> Within my application i try to update the row with the old version info, the
> row is not found and updated. No commit/rollback yet.
> Within my application i try to read the row without version condition, only
> by primary key and not for update.
>
> Then i get an SQLException (row could not be locked), saying, that not lock
> could be set within the definied time.
>
> I ran my application in debug mode to do the ij task between my own
> statements.
>
> There was another posting at 04/18/2007 "commit then read immediately" which
> sounds very simular.
>
> I'm not using any caching in my application.
>
> On other databases like Orcale and hqsl i don't have that problem. Whats
> wrong with the row locking? Why does a normal select try to set a lock?
>
> Thanks for your help.
>
> Kay
>
>
>
> --------------------------
> ckc ag
> Sitz:
> Industriestr. 10
> 38110 Braunschweig
>
> Telefon 05307 / 80 20 0
> Telefax 05307 / 80 20 444
> http://www.ckc.de
>
> Amtsgericht Braunschweig
> HRB 5405
>
> Vorstand:
> H.-G. Christian Krentel
> (Vorsitzender)
>
> Aufsichtsrat:
> Dr. Heinz-Werner Weinrich
> (Vorsitzender)
> Hans Bodenstein
> Dr. Rita Schulz
> --------------------------
>
>
>   
Hi -
I'd need a specific test case to tell what is going on.  Locking 
behavior is determined by the transaction isolation level, autocommit 
and the access method being used.  My guess is that adjusting the 
isolation level will give you the results you desire reagardless of 
access method.

Re: locking problem when selecting data

[Mark Thornton <mt...@optrak.co.uk>]

Kasper, Kay wrote:
> On other databases like Orcale and hqsl i don't have that problem. Whats
> wrong with the row locking? Why does a normal select try to set a lock?
>   
Unless your transaction isolation is TRANSACTION_READ_UNCOMMITTED, I 
think a row (or table) lock is required for any select.

Mark Thornton