Hi All, There are user requests to implement statement, transaction and attachment timeouts: http://tracker.firebirdsql.org/browse/CORE-658 http://tracker.firebirdsql.org/browse/CORE-985 http://tracker.firebirdsql.org/browse/CORE-4238
More - it was decided by TTG to implement this feature as mandatory on in fb4, see: http://www.firebirdsql.org/en/planning-board/ I am responcible for it, so i going to start discussion about it. Looking at tickets above we could see three kinds of timeouts: - statement timeout - to limit maximum statement execution time, - transaction timeout - to limit maximum lifetime of transaction, - session (attachment) timeout - to kill idle (inactive) session after some timeout. I see the main purpose of this feature as ability for database admins (DBA) to control "bad written" or "poorly\no supported" applications. I.e. DBA should be able to not allow wrong written queries to consume all resources, avoid idle transactions \ connections to run too long and so on. Also, statement timeouts could be useful for developers for stress-testing. I suppose that feature should be configurable at per-database\per-connection and per-statement levels. Per-database configuration should have highest priority to give power to DBA. I.e. application developers could make stronger limits than DBA but couldn't get around DBA. By default feature should be disabled, of course. Other mainstream DBMS already have support for active statement and idle session timeouts. I know no example of transaction timeout, though. I think, transactions timeouts could bring more troubles than goods and in many cases could be replaced by idle session timeouts. Therefore i offer to omit transaction timeouts from further discussion (but i not insist). I don't want to discuss implementation details until we reach agreement on feature as a whole, except of one important detail - where timeouts should be implemented: at the client side (y-valve\fbclient) or at the server side (engine). Client-side implementation could be based on already implemented ability to cancel statement execution asyncronously. Also, it potentially could take off some work from the engine (to track timeouts) and could be more precise from user point of view (as it will include network delays into time measurements). But client-side have also weak points: we still have no support for fb_cancel_execution at XNET protocol, asyncronous work always more complex and error prone, Java and .Net providers will be forced to create own implementation of this feature, it is hard detect if some statement should not be affected by timeout (DDL statements, for example). Therefore i offer to create server-side implementation of timeouts. So, below is high level overview of what i propose to implement: a) Statement execution timeout - timeout is set in milliseconds, there is no guarantee of exact precision (especially under high load). The only promise is that timeout will not happen earlier than specified - timeout value could be set - at databases.conf (or firebird.conf) by DBA - at runtime at session level - at runtime at statement level - value of zero means timeout is not set - effective value of timeout is evaluated every time statement execution is started using rules below: - if not set at statement level then look at session level - if not set at session level then look at config - can't be greater than (non-zero) value at config - when statement execution is started (exec()\open() methods), timeout timer is started - timeout tracked since the moment of the execution start, i.e. timer is not reset by the fetch() calls - timeout timer is stopped when statement execution is finished - at the end of exec() method or when the fetch() returns last record - if timeout happens at moment with no client activity (for example between two fetch() calls) it will not take immediate effect, i.e. cursor remains open and resources is not freed - when timeout happens the client call (open\exec\fetch) returns with primary error code isc_cancelled (same as asyncronous statement cancellation) and secondary error code pointed to exact reason of cancellation - timeout have no effect on DDL statements - timeout have no effect on internal statements executed by the engine itself - client could wait longer than expected if statement backout (undo) takes time b) idle session timeout - timeout is set in seconds, there is no guarantee of exact precision. The only promise is that timeout will not happen earlier than specified - timeout value could be set - at databases.conf (or firebird.conf) by DBA - at runtime at session level - value of zero means timeout is not set - effective value of timeout is evaluated every time timeout timer is started using rules below: - if not set at session level then look at config - can't be greater than (non-zero) value at config - timeout timer is started when user call of API function leaves the engine - timeout timer is stopped when user call of API function enter the engine - when timeout happens the engine immediately closes the attachment in the same way as with asyncronous attachment cancellation: - all active statements and cursors are closed - all active transactions are rolled back - next API call by client returns with primary error code isc_att_shutdown and secondary error code pointed to exact reason of cancellation - timeout have no effect on system attachments (garbage collector, encryption etc) Once we get agreement on said above i go to the more details (API changes, SQL support and so on) Thanks for opinions, Vlad ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
