All, I'd like to get opinions whether the "on disconnect" triggers should be fired in the cases when some connection is forcibly closed.
We have a number of cases that cause a more or less asynchronous disconnection: 1) server shutdown 2) database shutdown 3) connection shutdown via monitoring tables 4) connection shutdown by the remote server (broken network link) These triggers may be expected to react on all kinds of detaching. I hope nobody is going to depend on that in the business logic (obviously, a server crash will not cause triggers to fire), but some logging logic may be intended to log as many events as possible. From another side, (1) and (2) are quite time critical, as they usually executed with a timeout. (3) and (4) are not, but some users would prefer them to be executed as fast as possible. A good argument is that db-wise triggers are owned by a DBA who should be sane enough to avoid any long-running operations there. But let's not forget that every triggers starts and commits a transaction and it may cause a noticeable concurrent I/O and lock manager load for sites with hundreds of connections, thus slowing down the process. AFAIU, now (in the officially released versions) triggers are executed only in cases (1) and (4). I doubt this is intended, it looks more like an oversight. But before changing that, we need to agree on what is the correct behaviour: a) fire for all kinds of detaching b) fire only for regular disconnections c) fire in some cases from the above list and not in another ones Please comment. Dmitry ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel