--- 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.

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.

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?

Adam