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