--- In firebird-support@yahoogroups.com, "Adam" <s3057043@...> wrote:

>
> --- In firebird-support@yahoogroups.com, "burmair" <YahooSpam@> wrote:
> >
> > --- In firebird-support@yahoogroups.com, Helen Borrie <helebor@>

wrote:

> > >[...]
> > >Basically if you don't understand the effects of WAIT, don't use it.
> >
> > Often I don't even understand the effects of my own code, so I
> > wouldn't presume to know what's going on in the internals of a DB
> > engine. Everything I think I know came from pages 531+ of The
> > Firebird Book. Condition 2 doesn't apply, and the code (now) I think
> > effectively prevents condition 1 from ever occurring. So WAIT is
> > probably not needed and has been removed. But the hang still occurs.
> >
> >
> > > I think that having a single application that is connecting and
> > disconnecting from the same two databases constantly in short order
> > seems bizarre. I could see it throwing the lock manager into a state
> > of chaos...is this really production code or is it some kind of rigour
> > testing?
> >
> > Yup, it's really production code. However, this scenario is not the
> > normal mode of operation. One of the DBs is the "real" one, the other
> > is "special" in that it contains objects (or even fragments of
> > objects) that need to be merged into the model stored in the "real"
> > DB. The app loads the entire first DB into memory (attach, a couple
> > updates that basically log the use of the DB, lots of selects,
> > detach). Then the second DB is likewise loaded into memory, and a
> > somewhat complex merge is performed. Finally, the updated model is
> > written back out to the first DB. At that point, the second DB can be
> > discarded.
> >
> > The hang was occurring during the first update (logging the use of the
> > DB) when the second DB was loaded. I've made the problem go away by
> > simply skipping that update (who cares if the special DB was
> > accessed?). Now everything is working the way it's supposed to.
> >
> > Thanks for taking the time to look at this problem for me!
> >
> > Tim
> >
>
> Tim,
>
> An aside, is there any reason to actually disconnect? You can
> establish two separate connections, one to each database, start
> transactions and run queries against the relevant connection.

Good point. It was slightly more convenient to detach the first DB,
but with very little effort there could be two connections. I didn't
mention this to anyone, but there's actually a third DB involved that
does run on it's own connection (this DB contains the scripts that
automatically upgrade the first two DBs if and when needed).

>
> How frequently does your application "switch" databases. I would have
> assumed that you would need to be disconnecting / reconnecting
> multiple times per second before troubling the lock manager too badly.

Worst case, possibly one switch per month. Once a year is probably
more likely. This is a special operation, merging a few new pieces
into an existing model, and it's performed "offline". In any case,
there was exactly and consistently one switch before the hang occurred.

>
> A hang on an update is usually symptomatic of a lock conflict in a
> wait transaction. Maybe you weren't running the update on the database
> you thought you were?

In retrospect, this seems very plausible. But at this point we may
never know, since I've worked around the problem, and I long ago
stopped trying to explain every anomaly I encounter.

Thanks for your help!

Tim