18.08.2016 13:04, liviuslivius wrote: > If i can start general discussion.. > > do you really use such feature in real systems? > I saw this in MSSQL environment and what was advice of DBA when someone reach > timeout? > Increase timeout settings...
IIRC, default query timeout in MSSQL is 30 sec, and it is not configured at database level. More, it is pure client's feature. Therefore MSSQL devs a) often not know it is ever exists (until it happens in application) b) have no way except completely disable it or raise to high level in app code i could be wrong, but this is what i know about it > Kiling statement or transaction is not good as a general solution > It must be customized for situations. > > I suppose better feature will be "timeout messaging" - something like > TRIGGER ON STATEMENT_TIMEOUT > TRIGGER ON TRANSACTION_TIMEOUT > > and inside it we have access to MON$ tables and we can cancel statement, > transaction if we need. > Inside we can check e.g. individual context variables which eovercome some > default settings. > We can post event and some admin client application can take some action > i suppose you can run into more samples I'm very sceptical in that such trigger could have enough context info to make educated decision. Also, in what execution context (attahcment\transaction) it should run ? If it decided to not cancel statement - should it be fired again ? When ? I'm sure, there is a lot more such questions with no easy answers... > P.S. > What about statements executing query to external database by EXECUTE > STATEMENT? This is implementation detail i going to speak later. I think, the most logical is to apply rest of effective timeout to the external query (if target server supports timeouts) Regards, Vlad ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
