On 8/9/2013 8:37 AM, Katherine Marsden wrote:
On 8/7/2013 2:13 PM, Jasmeet Bhatia (jasmbhat) wrote:
I am troubleshooting a derby deadlock and need help. (setup - -Derby
10.7.1 + in-memory DB + Hibernate 3.6.9 + spring 3.0.3)
Inside a transaction, I execute delete on a specific instance of an
e
On 8/7/2013 2:13 PM, Jasmeet Bhatia (jasmbhat) wrote:
I am troubleshooting a derby deadlock and need help. (setup - -Derby
10.7.1 + in-memory DB + Hibernate 3.6.9 + spring 3.0.3)
Inside a transaction, I execute delete on a specific instance of an
entity that has a 1-* relationship with anothe
I am troubleshooting a derby deadlock and need help. (setup - -Derby 10.7.1 +
in-memory DB + Hibernate 3.6.9 + spring 3.0.3)
Inside a transaction, I execute delete on a specific instance of an entity that
has a 1-* relationship with another entity. This results in an update SQL that
tries to b
Blair Zajac writes:
> Knut Anders Hatlen wrote:
>> Blair Zajac writes:
>>
>>> I downloaded d2991-preview-1e.diff and applied it to r737572 of trunk.
>>> I don't see the original problem now. Even going to 500 threads and
>>> setting derby.locks.waitTimeout to -1 works.
>>>
>>> Will or when will
Kristian Waagan wrote:
Blair Zajac wrote:
Kristian Waagan wrote:
Blair Zajac wrote:
Hello Blair,
My only *guess* is that there might be a restructuring of a BTree
going on, which is not correctly reported - and you might be
experiencing a deadlock. To stop guessing and actually start
und
Knut Anders Hatlen wrote:
Blair Zajac writes:
I downloaded d2991-preview-1e.diff and applied it to r737572 of trunk.
I don't see the original problem now. Even going to 500 threads and
setting derby.locks.waitTimeout to -1 works.
Will or when will a patch for d2991 be applied to trunk?
Tha
Blair Zajac wrote:
Kristian Waagan wrote:
Blair Zajac wrote:
Hello Blair,
My only *guess* is that there might be a restructuring of a BTree
going on, which is not correctly reported - and you might be
experiencing a deadlock. To stop guessing and actually start
understanding what's going
Blair Zajac writes:
I downloaded d2991-preview-1e.diff and applied it to r737572 of trunk.
I don't see the original problem now. Even going to 500 threads and
setting derby.locks.waitTimeout to -1 works.
Excellent! This is great news. External verification of this patch
will be very helpful
Blair Zajac writes:
> I downloaded d2991-preview-1e.diff and applied it to r737572 of trunk.
> I don't see the original problem now. Even going to 500 threads and
> setting derby.locks.waitTimeout to -1 works.
>
> Will or when will a patch for d2991 be applied to trunk?
Thanks for testing the p
Kristian Waagan wrote:
Blair Zajac wrote:
Hello Blair,
My only *guess* is that there might be a restructuring of a BTree going
on, which is not correctly reported - and you might be experiencing a
deadlock. To stop guessing and actually start understanding what's going
on, it would be grea
Blair Zajac wrote:
Hello,
I have a test case for my JDBC DAO layer that runs 50 concurrent threads
all inserting the same data to ensure that the DAO does not throw an
error if the data is already in the table (more details on the app
below). After working a while Derby 10.4.2.0 stops making
Hello,
I have a test case for my JDBC DAO layer that runs 50 concurrent threads all
inserting the same data to ensure that the DAO does not throw an error if the
data is already in the table (more details on the app below). After working a
while Derby 10.4.2.0 stops making progress, the java
Hi Bryan (sorry for the misspelling lat time),
The insert transaction is really simple (see below) so I am pretty
sure it doesn't do anything else else. In support of that, I want to
say that the deadlock trace does not reflect the LOCKCOUNT. There are
literally about 150 lines in the trace even t
Oh, and one more observation. The IX table lock for the insert thread
mentions LOCKCOUNT=476. I can only infer the meaning of the column (so
this might perfectly normal), but the number of row locks of that
connection is about 150 (it could not exceed 200, the number of
inserts I do per transactio
Oh, and one more observation. The IX table lock for the insert thread
mentions LOCKCOUNT=476. I can only infer the meaning of the column (so
this might perfectly normal), but the number of row locks of that
connection is about 150 (it could not exceed 200, the number of
inserts I do per transaction
Hi Brian,
OK, I see. What I said about escalation is wrong. I looked with new
eyes at the trace (see a more relevant summary below) and here's what
appears to happen:
- 216 (the select thread) holds a lock on 1,1 and waits for a lock on 1,7
- 183 (the insert thread) holds many locks, including
> Now, I have a pretty simple unit test that results in a deadlock:
> - one thread is inserting records in a table (in transactions of N=200
records)
> - another thread comes from behind and reads the same records (select
> * where id > $lastReadID)
>
> After examining the deadlock trace the ex
First of all hello to all derby users,
Now, I have a pretty simple unit test that results in a deadlock:
- one thread is inserting records in a table (in transactions of N=200 records)
- another thread comes from behind and reads the same records (select
* where id > $lastReadID)
After examinin
Derby has debug flags that prints out the lock table information to
derby.log, and this can help debug lock timeout/deadlock errors. The
following faq entry talks about how to enable these flags.
http://incubator.apache.org/derby/faq.html#debug_lock_timeout
Hope this helps, but please do pos
During development, I am sometimes doing stupid things that result
in lockups (embedded server, btw). When I find and fix the bugs, the
lockups generally go away... but is there an easier way to find out what
& where a deadlock was caused by, who/where locked the table concerned,
and so on, just t
20 matches
Mail list logo
