db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <Kristian.Waa...@Sun.COM>
Subject Re: Row Locking
Date Mon, 04 May 2009 13:01:09 GMT
wfalby wrote:
>
> Kristian Waagan-4 wrote:
>   
>> wfalby wrote:
>>     
>>> My application processes events. These events are sent to registered
>>> users.
>>> These events can be deleted when they reach a certain age. There is a
>>> thread
>>> to send events to registered users and there is another thread to delete
>>> old
>>> events. The thread sending an event should lock it from the thread that
>>> deletes old events. Each thread uses its own connection to the database.
>>> In
>>> the sending thread, I've tried using a SELECT ... FOR UPDATE and setting
>>> the
>>> ResultSet.CONCUR_UPDATABLE on the prepare statement. In both cases, the
>>> thread that deletes events deleted the event being held by the sending
>>> thread. The default isolation level and autocommit options are used.
>>>   
>>>       
>> Hi Walter,
>>
>> If you're using the read committed isolation level, I think you need to 
>> use SELECT ... FOR UPDATE WITH RS.
>> Which behavior do you see if you do that?
>>
>> I think Derby treats SELECT ... FOR UPDATE a bit differently than some 
>> other database systems, and I also believe there is at least one Jira 
>> [1] issue logged for changing the behavior.
>>
>>
>> Regards,
>> -- 
>> Kristian
>>
>> [1] https://issues.apache.org/jira/browse/DERBY
>>     
>>> Thanks in advance...Walter
>>>   
>>>       
>>
>>     
>
> Kristian:
>
> Thanks for the info. I tried your suggestion, but all rows are deleted. I'll
> check the Jira issue to see if it fits my situation.
>   

Reading your post again, I see that you're using the default autocommit 
option. The default in Derby is that autocommit is on.
I haven't seen your code, but doesn't that mean that the locks will be 
released immediately, most likely before the sending thread has finished 
its work?

One way to debug this would be to query the lock table to verify that 
the sending thread actually causes an exclusive lock to be set. There is 
some information about this at http://wiki.apache.org/db-derby/LockDebugging


HTH,
-- 
Kristian

> Walter
>   


Mime
View raw message