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
