The problem seemed somewhat familar, I did a quick scan of resolved
issues in Derby and DERBY-94 which was fixed seemed like it MIGHT apply.
If you still have a reproducible test case where you can show a lock
remaining in a select * from the lock table after that transaction
commits. And it reproduces against the latest version of the
code please log a JIRA.
Klas U. wrote:
> Hi!
>
> (Just to make clear: Legolas Woodland and I have a similar Problem with
> remaining locks, but different environments...)
>
> I had the "remaining locking" problem with Derby 10.0.2.1 on IBM (AIX).
> After updating to Derby 10.1.1.0 I *could not* reproduce the effect again!
>
> Additional info: for our Derby 10.0.2.1 environment we used the IBM DB2 JDBC
> Driver (comming with the incubating distribution), now (with 10.1.1.0) we
> switched over to the "original" Derby JDBC driver classes. Maybe this had
> some influences...?
>
> Regards,
> Klas.
>
>
>>-----Original Message-----
>>From: Legolas Woodland [mailto:legolas.w@gmail.com]
>>Sent: Saturday, January 28, 2006 9:42 AM
>>To: Derby Discussion
>>Subject: Re: Deby create LOCK on my table and do not release
>>it , what is my mistake ?
>>
>>Hi
>>Thank you for reply.
>>Im using version 10.1.2.0 , on windows XP sp2.
>>I use regular isolation level (i did not changed any thing ) , i just
>>execute my querys.
>>I will answer other question about lock table asap.
>>
>>Mike Matrigali wrote:
>>
>>>some suggestions.
>>>
>>>Do you have the ability to try it out with a more recent version of
>>>Derby, say the latest 10.1 release?
>>>
>>>In debugging this what I would do is set the property to output the
>>>queries to the derby.log. The faq on debugging lock
>>
>>timeout's apply's
>>
>>>to your situation:
>>>http://db.apache.org/derby/faq.html#debug_lock_timeout
>>>
>>>Just to veryfy, when you do select * from the lock table,
>>
>>are you only
>>
>>>seeing one row - or are you editing the information for the
>>
>>post? If
>>
>>>there are more rows, please post complete lock table info.
>>
>>If there is
>>
>>>only one row, then there is definitely a problem.
>>>
>>>Also could you post which isolation level you are running at. read
>>>committed is the default.
>>
>>(...)
>
>
>
>
|