[Progress Communities] [Progress OpenEdge ABL] Forum Post: RE: Transactions and Undos. Novel

Status
Not open for further replies.
G

gus bjorklund

Guest
Hi george. lots of good stuff in you article. i have a few random things to add. 0) the transaction id is a 32-bit signed integer that increases monotonically. when it becomes negative because it has rolled over, it is reset to 1. not all possible transaction id values can be used. transaction id’s have to be positive because we used the negative of the transaction id as a lock in deleted unique indexes and for deleted records to lock the rowid until transaction end. the mb_txnSequence counter is there to enable construction of unique 64-bit transaction id’s from it and the transaction id. 1) allocated or active transactions have two numbers that are related but different: the transaction id and the transaction table entry or slot number. the entry number can be derived from the transaction id. 2) the size of the transaction table is derived from -n + -Mn + 2. (one entry per server, one for the primary broker, and one reserved for proshut). that number is the size of the connection table and the maximum allowed number of concurrent transactions. the transaction table size is rounded up to the next larger power of two but the extra entries are not used. (when crash recovery or warmstart is completed, the table size changes from the one used for crash recovery to the one that will be used for forward processing). 3) when a new transaction id is to be generated, we start with the last transaction number in the master block and add one. a transaction table table entry number is then obtained by taking the low order bits of the transaction id (anded with table size -1). if the entry is in use by another transaction, then we try the next larger value until we get a slot number larger than the maximum number of concurrent transactions, after which we jump forward to the next transaction id that matches the first transaction table entry. lather, rinse, repeat as needed. 4) when two-phase commit is in effect, there are two transaction tables, the regular one and another for transaction that have been prepared. 5) the “per tx” numbers in promon are somewhat inaccurate but i would not characterize them as meaningless. i have found them useful at times. same as when the speedometer in your car says 150 kph but we know it is not true because they all read a higher than the true value. 6) the “jump notes” are used during rollback to skip over bi blocks that do not contain notes written by the transaction being rolled back. 7) you are right that dbtaskid() returns data from the client’s memory, except the first time it is called in a new transaction. in that case, the client asks the database for it.

Continue reading...
 
Status
Not open for further replies.
Top