Hi Maya,

I'm also having this issue on the official 2.5.0 release. Now, as far as
i remember, it has been fixed monthes ago and should work with the
latest snapshot (didn't test it).
This is/was due to the use of "post event" which crashes the server.
http://tracker.firebirdsql.org/browse/CORE-3170

Greg

Le 03/06/2011 09:41, Maya Opperman a écrit :

>
> Hi Norm,
>
> >> And this on insertion of new support incidents:
> >>
> >> IF (NEW.ID IS NULL) THEN
> >> NEW.ID = GEN_ID(GEN_CUSTOMERINCIDENTS_ID,0);
> >>
> >> (Which the person who originally wrote the app put in there,
> >> which I'm not so sure it's even needed...the FIBPlus
> >> component should be handling this AFAIK)
>
> >This is most likely for data protection and integrity.
>
> Yeah, I was thinking about that while eating breakfast - it'll
> probably be best to leave it alone. The other tables don't have it,
> but there was probably an odd situations where it was required, and
> made a certain function easier to program.
>
> >> I think the next thing I'll try though, after setting up a
> >> dummy server (if the problem persists on the other server),
> >> will be to restore the database, to get it onto the new ODS,
> >> and see if that changes anything.
> >If the problem is a deadlock, I don't think a new ODS will help much.
> >Deadlocks are almost always application generated.
>
> The thing is, on all the other versions of Firebird I have used in the
> past (Firebird 1.5.4, 1.5.5, 2.1.3, 2.1.4 and 2.1.5 ) I have never had
> this problem.
> ALL I am doing is updating the server version to 2.5, nothing else.
> And reverting to 2.1 goes back to normal again.
>
> How can I be sure it IS a deadlock? Is the how deadlocks behave?
> Locking up the ENTIRE database?
>
> >> BTW, I use no_wait for all my transactions, so I usually get
> >> a deadlock exception rather than a hang.
> >What does the application do when it gets a deadlock exception? Does it
> >rollback and try again? Is it possible that more than two transactions
> >are involved and the deadlock is actually, a deadly embrace?
>
> It rolls back the transaction, and re-raises the exception, so the end
> user see's the message. No message is being seen by either of the users.
>
> >> It's also so locked up, I can't get into the database at all.
> >When you try, and fail to get in, does the firebird.log tell you
> anything useful?
> If I try open via IBExpert it just hangs.
>
> >> If it was just a deadlock, surely I should be able to at least get to
> the
> >> monitoring tables? And into other tables in the database that are not
> >> locked up?
> >I would assume this to be the case. But as you said earlier, you are on
> >2.5 and there are a couple of "complaints" about 2.5 on this list at the
> >moment. If there is a 2.5 problem, maybe you are hitting it.
>
> If it is a deadlock, then it's a deadlock that's happening on FB 2.5,
> and NOT happening on FB 2.1
>
> And which isn't looking at my no_wait settings. So maybe something
> very low level. A system table perhaps...
>
> BTW, it's not a concurrency thing. I don't have to create the 2
> records simultaneously, user B just has to have inserted into that
> table at some stage, then when user A tries again later - HANG.
>
> I think what I must do as well when I have the dummy test server set
> up, it to try add the record via IBExpert. That way I'll be able to
> tell if it's just something in about that table, or whether some of
> the weird and wonderful complicated refresh code, or one of the data
> aware editing components in the application is causing the problem.
>
> Thank you for your ideas ;-)
>
> Maya
>
>

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