On 4/2/2014 7:05 PM, Vlad Khorsun wrote: >> On 4/2/2014 5:28 AM, Vlad Khorsun wrote: >>>> C >>>> I think it will be not easy to implement from the Y-valve point of >>>> view - i see no simple way to pass handles from one >>>> process >>>> (coordinator) to another (worker). Especially, in the case of Classic >>>> Server. >>>> >>>> Instead, i think, we could implement something like "clone >>>> transaction" which will: >>>> - get "master" transaction number at input >>>> - create new transaction with new number : >>>> - transaction parameters will be the same as of "master" transaction >>>> - transaction private markers (oldest active, oldest snapshot) will >>>> be the same as of "master" transaction >>>> - transaction private copy of TIP will be the same as of "master" >>>> transaction >>>> >>>> >> Why not use the transaction info call to get a snapshot of the >> transaction state vector (or whatever I called it) and other transaction >> state, pass the stuff in the transaction parameter block, and create an >> exact transaction clone on the other connections. > You offer to introduce no new API call's - it is good. > But you also offer to pass private copy of TIP via user application - it is > - not efficient in a network environment > - not secure, as allows applications to create transactions with random > contents of a TIP > Therefore i don't like this.
That's an easy problem to solve -- encrypt or obfuscate the transaction state vector. I don't see why the network environment make any difference one way or the other. A modest block of gook -- no problem. I'm not talk about sending the tip, but only the snapshot of "interesting" transaction captured when the original transaction started. > > But idea to pass tx number with some special tag in TPB to make clone of > given transaction is > good and allows us to not introduce new API call. > >> Two transaction >> objects with the transaction id would be chaos it there were updates, > Exactly > >> but there aren't. I don't quite know how commit would work, but... >> >> But I think it would be more fun to think of Sean's backup problem in >> terms of a multi-threaded shared procedure executing off a single >> transaction object. Vulcan had a fine grained multi-threading >> architecture that could handle that, but I don't really know anything >> about the new version. > It can't work in classic mode. As for SS mode - yes, technically, > transaction object is > almost read-only thing and it seems possible to safely share it between > attachments in > the same process. And it could satisfy Sean requirements, at first look. It works just fine in classic. All a transaction needs is a snapshot of the interesting part of the TIP when the transaction started. Commit is a tad dicey in classic, but if the other problems could be solved, I'm sure a solution for that could be found, too. > > I consider limitations of this model too strong to make the feature > widely used. > But this is just my opinion. > > Regards, > Vlad > > > ------------------------------------------------------------------------------ > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
