Subject Re: What to do with old, active (unresolved, hanging) transactions?
Author vincent_kwinsey
Well - as I understand - there are 2 news, as usually - one good and
one not so god.
1) the good news are that in principle some problems in application
design cann't lead to errors like 'lock conversion denied', 'lock
denied'
2) the not so good news items is, that on-disc structure has got
corrupted and hence these messaged. Am I right? Well, it may be so,
but - if this is true - are these type of corruption bad and can this
go to other records as well? Should be take immedate action and try
to make gfix or backup-restore?

--- In firebird-support@yahoogroups.com, "Ann W. Harrison"
<aharrison@...> wrote:
>
> vincent_kwinsey wrote:
> > Hi,
> >
> > I am experiencing the following error messages:
> > page type 5 lock conversion denied (215)
> > page type 5 lock denied (216)
>
> Those errors are on internal structures - which should be deadlock
> free. Deadlocks in applications happen, but the pages in the cache
> should not cause deadlocks.
>
> > and there are frequent deadlock errors in application. I guess,
that
> > application is leaving many transactions in unresolved state (not
> > committed, not rollbacked) and any deadlock only increase amount
of
> > unresolved transactions, and hence - the amount of locks on
records.
>
> Transactions can't be "unresolved" - they're either active and
belong
> to a client that has an active connection, or they're committed,
> rolled back, or in limbo. The latter happens only when you've got
> two or more databases active in the same transaction and a very
> unfortunate termination in the middle of a two-phase commit.
>
> User transactions and their states should have no effect on internal
> data structure conflicts, which are what the two messages above
> indicate.
>
> >
> > So - my question is - what happens with these transactions and
locks?
> > Are they remaining on database forever? A operations guide
provide
> > information that backup/restore and gfix can recover
transactions 'in
> > limbo' - but these are for two-phase commit.
>
> When a connection ends or the program that created the connection
ends,
> all active transactions in that connection are rolled back.
> >
>
> Regards,
>
>
> Ann
>