Re: [Firebird-devel] Forced detach vs ON DISCONNECT triggers

[Vlad K. <hv...@us...>]

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

    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.

Regards,
Vlad