For mysql XA there is no possiblity to join transaction, thus when tmsrv creates transaction the atmi_xa_start_entry and atmi_xa_end_entry calls possibly are not needed.
#1 Updated by Madars Vitolins about 1 month ago
- Subject changed from tmsrv optimiztaions to tmsrv optimizations
For some databases like mysql and postgresl we might need to support for one resource manager several (may be thousands) of branch qualifiers This may be built by cluster node id, resource manager id, process id, timestamp, and sequence number within the process.
Each time process starts the transaction, it requests the new xid tmsrv. then this "branch" shall be associated with the "resource manager id"/group. These xids must be logged. When performing the prep/commit/abort of the transaction, we shall loop over the xids assoced and perform the action. The result of each xid must be logged. The final result of "RM" shall be given as worst status of we have.
- with new begin, we generate xid
- when process performs xa_end, we shall call prepare for that transaction
- when tmsrv calls prepare again for all of the transactions, if any of them fails, then we shall go to abort phase, due to fact that some process have not completed it's duties.
#3 Updated by Madars Vitolins 20 days ago
tpsuspend() -> for prosgres we prepare tran. For Mysql we end tran.
tpresume() -> we request new XID from TMSRV.
When flag "TPTRANSUSPEND" is set for tpcall() no suspend is needed, because target invocation will be in different branch, thus no locking will be required.