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:[EMAIL PROTECTED]
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.
(...)
