> > As far as I can tell, there is no way for this to be done. > > I'd said you need "common snapshot". I.e. few transactions should use the > same snapshot view of database.
Correct. > Instead, i think, we could implement something like "clone transaction" "Clone Transaction" would meet my definition. > At the applications side : > - some worker process starts transaction, get it number, and pass it to the > other worker processes > - this first worker should not end its transaction until all other workers > clones > it > - all other worker processes should call "clone transaction" instead of "start > transaction" > - after this phase all worker processes free to do anything they usually could > do within usual transactions. Really? Could connection #1 commit a transaction, that connection #2 is "sharing"? > Note, it have no sence for read-committed transactions (as they have no > snapshot to share\clone) and for "consistency write" transactions (as they > will conflict on relations locks on concurrent write attempts). I.e. > it will work for "concurrency read\write" and for "consistensy read" modes > only. For my purposes only supporting "concurrency read\write" transactions would be fine, since it meet the direct requirements outlined. But support for writes, would allow for data pump type applications to insert data into the database under a single transaction "umbrella". Sean ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
