Здравствуйте! Monday, September 14, 2015, 10:22:02 PM, you wrote:
>>From my tests, it doesn't seem to be the case. It seems that, as soon as one >>commits or rolls back the started transaction, isql starts a new >>transaction using the global default (READ WRITE WAIT ISOLATION LEVEL >>SNAPSHOT). At least, that is what the tests seem to indicate. Sure. I mean, this is correct, and corresponds to the defaults of IB/FB API. If no parameters were passed to isc_start_transaction, it will be read write wait snapshot so, none "defaults" are changes until non-default parameters are specified. Everything corresponds even to old InterBase API guide. ISQL totally follows SET TRANSACTION specification, with all defaults, and not changing any defaults during it's work (as it was said by Mark). But, as it was mentioned in Re: [Firebird-devel] [NO] RECORD_VERSION topic, each driver or component set can have it's own default transaction parameters. For example IBX with no transaction params starts default api transaction - read/write wait snapshot. FIBPlus - starts read/write nowait read_committed rec_version by default. etc. Need to say that current transaction defaults can confuse programmer, initially. default "read/write wait snapshot" causes developer to think that "changes are not being saved until application ends". Because he, at first, do not understand "snapshot" behavior, not common for other databases. default "no_rec_version" for read_committed also confuses people, because it "blocks reading of concurrent uncommitted changes". Jiri said that "that was Dmitry Kuzmenko's wild ride 3-4 years back." and I was really mad by this. Because developers implementing drivers were not thinking about usability of isolation levels, and implementing "defaults" as is. And I said that "seems that they are not writing applications using their drivers". BDE until version 4.1 had that read_committed behavior - blocking readers, mostly silent. I reported it to Borland, it was fixed in 4.1 and later. Firebird ODBC had that behavior, until 1.5.2 version (IIRC) http://tracker.firebirdsql.org/browse/ODBC-120 great thanks that it was fixed. Firebird .Net driver had (have?) this behavior http://tracker.firebirdsql.org/browse/DNET-337 ? Jiri said that "it's up to developer that uses this driver". Can you imagine developer that starts to write first application with Firebird and knows ALL firebird transaction parameters, including defaults? Me - no. Current defaults mostly the reason of Firebird being blamed, silently. People ties to work with FB, find strange behavior, then drops using it not asking anyone about what happens. -- Sincerely, Dmitry Kuzmenko, www.ibase.ru ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
