Re: [Firebird-devel] Semantics of isc_tpb_autocommit
On 5/30/2015 10:48 AM, Dmitry Yemanov wrote: 30.05.2015 11:29, Mark Rotteveel wrote: To better understand the implications of the pull request by Maxim, I'd like to know the semantics of isc_tpb_autocommit. Is this documented anywhere? I'm not aware of any place. I'd especially like to know at which point the commit is executed, and the impact this has on open resources (cursor, blob, etc). As far as I understand commit_retaining is used. What impact does that have on visibility of transactions and resource use? Autocommit is executed at the end of every execute/fetch DSQL API call and every start/send/receive/transact BLR API call, and *only* if that API call modified some data or posted some event. As a side effect, this means that a select from a stored procedure that modifies data may cause multiple autocommits. A regular commit-retaining is used internally, so the same visibility/resource characteristics apply. I believe auto-commit was a Borland innovation. Like almost everything else Borland did, it is likely to be shallow and ill-thought out. More specifically, a commit executed within the context of a running BLR block is really quite dangerous. Commit retaining is something I did to honor SQL semantics. It's a hack and a misnomer. It really starts a new transaction inheriting the context of the original and previous auto-commit transaction. It has virtues of a clever standard-conforming hack and very little else. Changing the transaction of a running BLR statement is OK if everything possible BLR statement has been rigorously coded, a somewhat dangerous assumption. Or, perhaps more safely, it should work with the type of BLR generated by compilers, DSQL, and most utilities, but it will not work at all with valid but unorthodox BLR. It is legal, for example, to have a BLR send or receive in a substatement block of a BLR store verb, but which transaction -- the parent or offspring -- the applies to the store is highly problematic (meaning inconsistent and probably buggy). -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Semantics of isc_tpb_autocommit
On 30-5-2015 17:13, Vlad Khorsun wrote: I'd especially like to know at which point the commit is executed, and the impact this has on open resources (cursor, blob, etc). As far as I understand commit_retaining is used. What impact does that have on visibility of transactions and resource use? A bit simplified overview of autocommit code: when transaction, marked as TRA_autocommit performs any of following actions, it is marked also as TRA_perform_autocommit: - insert - update - delete - select with lock - post event TRA_perform_autocommit flag is checked when: - engine receives input message - engine send output message - engine stars to execute request - engine finished to execute DDL request When TRA_perform_autocommit flag is detected, engine run on-commit triggers (not for DDL, btw, looks like a bug) and performs commit retaining. New transaction have TRA_autocommit flag set and TRA_perform_autocommit not set. Thanks! Mark -- Mark Rotteveel -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Semantics of isc_tpb_autocommit
On 30-5-2015 16:48, Dmitry Yemanov wrote: Autocommit is executed at the end of every execute/fetch DSQL API call and every start/send/receive/transact BLR API call, and *only* if that API call modified some data or posted some event. As a side effect, this means that a select from a stored procedure that modifies data may cause multiple autocommits. A regular commit-retaining is used internally, so the same visibility/resource characteristics apply. That does mean I have studying to do ;) I have never done anything with commit retaining before; I just heard the horror stories ;) Mark -- Mark Rotteveel -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Semantics of isc_tpb_autocommit
On 30-5-2015 10:29, Mark Rotteveel wrote: To better understand the implications of the pull request by Maxim, I'd like to know the semantics of isc_tpb_autocommit. Is this documented anywhere? I'd especially like to know at which point the commit is executed, and the impact this has on open resources (cursor, blob, etc). As far as I understand commit_retaining is used. What impact does that have on visibility of transactions and resource use? I'd also like to know when isc_tpb_autocommit was introduced. Mark -- Mark Rotteveel -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Semantics of isc_tpb_autocommit
To better understand the implications of the pull request by Maxim, I'd like to know the semantics of isc_tpb_autocommit. Is this documented anywhere? I'd especially like to know at which point the commit is executed, and the impact this has on open resources (cursor, blob, etc). As far as I understand commit_retaining is used. What impact does that have on visibility of transactions and resource use? Mark -- Mark Rotteveel -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Semantics of isc_tpb_autocommit
30.05.2015 11:53, Mark Rotteveel wrote: I'd also like to know when isc_tpb_autocommit was introduced. Somewhen before Firebird was created. Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Semantics of isc_tpb_autocommit
30.05.2015 11:29, Mark Rotteveel wrote: To better understand the implications of the pull request by Maxim, I'd like to know the semantics of isc_tpb_autocommit. Is this documented anywhere? I'm not aware of any place. I'd especially like to know at which point the commit is executed, and the impact this has on open resources (cursor, blob, etc). As far as I understand commit_retaining is used. What impact does that have on visibility of transactions and resource use? Autocommit is executed at the end of every execute/fetch DSQL API call and every start/send/receive/transact BLR API call, and *only* if that API call modified some data or posted some event. As a side effect, this means that a select from a stored procedure that modifies data may cause multiple autocommits. A regular commit-retaining is used internally, so the same visibility/resource characteristics apply. Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Semantics of isc_tpb_autocommit
30.05.2015 11:29, Mark Rotteveel wrote: To better understand the implications of the pull request by Maxim, I'd like to know the semantics of isc_tpb_autocommit. Is this documented anywhere? AFAIR, no I'd especially like to know at which point the commit is executed, and the impact this has on open resources (cursor, blob, etc). As far as I understand commit_retaining is used. What impact does that have on visibility of transactions and resource use? A bit simplified overview of autocommit code: when transaction, marked as TRA_autocommit performs any of following actions, it is marked also as TRA_perform_autocommit: - insert - update - delete - select with lock - post event TRA_perform_autocommit flag is checked when: - engine receives input message - engine send output message - engine stars to execute request - engine finished to execute DDL request When TRA_perform_autocommit flag is detected, engine run on-commit triggers (not for DDL, btw, looks like a bug) and performs commit retaining. New transaction have TRA_autocommit flag set and TRA_perform_autocommit not set. Regards, Vlad -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
