Adriano, > 1) A server (not database server) receives a request and dispatch it to others > servers for extra processing and more than one server need to access the > same database in a consistent way. > > 2) A multi-threaded program (may be a future version of gbak) wants to > dispatch simultaneous queries to Firebird, so need to use more than one > attachment and transaction and then do not have transaction consistency.
I had been thinking about the multi-threaded program problem for a while, but I had always thought of the problem from the point of view of a Master transaction/connection wanting to create "clone" transaction handles (multiple clones allowed) which could then be "farmed out" processes. The thought being, that it would not be appropriate for just any connection to base from any " transaction" but rather than the context have initiated at the 'source' (this would also ensure that the master/clone links would be simply managed by the master). > I propose a clause to SET TRANSACTION (and its TPB) so user can inform a > "base transaction number" (better words and syntax are welcome). > > SET TRANSACTION ISOLATION LEVEL SNAPSHOT FROM BASE 100 In my mind, the clone handle would be a GUID that could only be passed in TPB to establish the correct context, never set via SQL. > In this case, 100 must be an active transaction and the snapshot of the new > transaction will be the same snapshot used when transaction 100 was > started. IMO, this is a must -- the transaction rules of the Master transactions must apply to all clones. > New transaction will not get uncommitted changes of transaction 100. Why not? IMO, as far as the client and server are concerned the clone is transaction 100. This would allow for the clone transaction GUID to be passed from process to process and allow each to see where the last 'left off' It also seems the simplest way to manage garbage/version cleanup. Only the Master transaction can be committed -- affecting all clones. > With this, a program (or a set of coordinated programs) may use same > Firebird database in multi-threaded / multi-process way preserving read > transaction consistency. > > New semantics may also be introduced to use non-active transaction as base > number and a policy to retain some garbage for a period so one can do time- > lapsed queries. This is, however, out of the scope of this proposal. But that seem more of a new "freeze point" main transaction than a sub/clone transaction. > > > Adriano > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most engaging > tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing > list, > web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
