On 12/24/12 11:59, Vlad Khorsun wrote: >> 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.
Sometimes such things are simply called bugs ... >> 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. > I prefer (a). Probably, if it is strongly necessary, i'd add option in > trigger type > to distinguish forced detach from normal, for example > > CREATE TRIGGER ... ON [FORCED | NORMAL | ANY] DISCONNECT > > ANY is by default. > > It allows to not fire NORMAL trigger on forced detach and not start new > transaction. > > Also, despite of option above, it will be useful to have ability to know > type > of detach inside trigger. It could be implemented by new system function > (like INSERTING/UPDATING/DELETING, say FORCED_DETACH) or by new > context variable in session namespace. > I agree with Vlad. Just one detail - case 4 should better be treated as NORMAL. Nothing forced in lost network connection or hanged station. ------------------------------------------------------------------------------ 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
