Hi Ann,

I'm not using any transaction level explicitly. I'm using JPA and what I see in the trace is always this:
READ_COMMITTED | REC_VERSION | WAIT | READ_WRITE

I will wait now until it happens again (maybe in five minutes or a week) and then I will perform a full lock print as suggested.

What I would be interested in is what kind of SQL pattern could produce such a deadlock that basically kills Firebird? Would I see anything in the trace?

Best regards
Freddy

Von: firebird-support@yahoogroups.com [mailto:firebird-support@yahoogroups.com]
Gesendet: Dienstag, 9. Mai 2017 16:43
An: firebird-support@yahoogroups.com
Betreff: Re: AW: [firebird-support] RE: Firebird SuperClassic hangs

> On May 9, 2017, at 9:10 AM, Freddy Ertl F.Ertl@... [firebird-support] <firebird-support@yahoogroups.com> wrote
>
> that's the question, that I have: How to find out what causes the deadlock scans. I have thousands of transactions per minutes, doing all possible kind of things. What to look for? Where?

Your lock header reported an actual deadlock which is actually quite rare. If at all possible, instrument your code to find actual deadlock errors ignoring the more common "update conflict" errors.

And, although I'm sure you've said it before, wha transaction isolation level are you using?

Good luck,

Ann

>
> Best regards
> Freddy Ertl
>
> Von: firebird-support@yahoogroups.com [mailto:firebird-support@yahoogroups.com]
> Gesendet: Dienstag, 9. Mai 2017 15:05
> An: firebird-support@yahoogroups.com
> Betreff: RE: [firebird-support] RE: Firebird SuperClassic hangs
>
>
>
>> Deadlock scans: 289, Deadlocks: 1, Scan interval: 10
>
> Is probably the culprit, 289 deadlock scans, one actual deadlock found....
>
> "Deadlock scans. The number of times that the lock manager walked a chain of
> locks and owners looking for deadlocks. The lock manager initiates a deadlock scan
> when a process has been waiting 10 seconds for a lock."
>
> "Deadlocks. The number of actual deadlocks found, A deadlock occurs when
> Process A, wants a lock on Resource 1 which is held in an incompatible mode
> by Process B and Process B wants a lock on some Resource 2 which is held in an
> incompatible mode by Process A.
>
> "Each owner stands around glowering at the other and neither will do anything
> to improve the situation, so the lock manager returns a fatal error to one or the
> other. Deadlocks can also occur with a single resource if both owners start with
> read locks and request conversions to write locks. However, deadlocks always
> involve two owners (or two separate transactions)
>
> Errors that are returned as "lock conflict" from "no wait" lock requests will not
> be recorded in the lock table as deadlocks because only one owner is waiting.
>
> Errors returned as "deadlock" with a secondary message specifying "update conflicts
> with concurrent update" are not actual deadlocks either. What has happened in those
> cases is that one owner has modified (or erased) a record and moved on. Another
> concurrent owner has attempted to modify (or erase) the same record, noticed that the
> most recent version is one he can't see waited to find out how the other transaction
> ends up, and found to his disappointment, that the other transaction succeeded.
> In that case, our patient transaction can't modify the record because it can't find
> out what its late contemporary actually did."
>
> "Scan interval. The lock manager waits some period of time after a request starts
> waiting before it starts a deadlock scan. The default interval is 10 seconds, which may be
> long considering the change in CPU performance since 1983. Deadlock scans should not be done
> whenever there's a wait because waiting is normal and scans are not free."
>
> A deadlock scan would cause your server to hiccup while the lock manager tries to
> find if there is a real deadlock within the lock manager. You might want to investigate
> why deadlock scans are being instigated..
>
> With thanks to Ann Harrison :-)
>
> Regards
> Paul Beach
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
> Posted by: Freddy Ertl <F.Ertl@...>
> ------------------------------------
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://www.firebirdsql.org and click the Documentation item
> on the main (top) menu. Try FAQ and other links from the left-side menu there.
>
> Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> ------------------------------------
>
> Yahoo Groups Links
>
>
>

[Non-text portions of this message have been removed]