[Progress Communities] [Progress OpenEdge ABL] Forum Post: RE: Question about transaction that spans MSS DataServer and OpenEdge DB

[gus bjorklund]

Sorry, there are no docs on two-phase commit other than what the dataserver docs and the database administration guide has. The 4GL does two forms of two-phase commit with OpenEdge databases and one (i think maybe not documented) with dataservers. It is technically possible to make sonic messages transactional (i think sonic supports JTA (Java’s two-phase commit API)). This would mean that if a global transaction rolls back, messages are not sent and database changes are undone. This is not an easy project - the devil is in the details. most of the interesting failure modes involve crashes and other things (e.g. network outages) that happen during commit processing. furthermore, if a failure occurs after all the participants are ready to commit, then ensuring that all the participants reach the same result is not easy and requires special-purpose maintenance tooling. JTA is the Java Transaction API, which is supported by the OpenEdge database (careful what you wish for). Using it requires another component called a transaction manager. The TM is responsible for maintaining the association among global transaction identifiers generated by the TM and the local ones generated by the individual participants, orchestrating the details of successful transaction commitment, and dealing with any required transaction recovery in the event of a failure after commit processing starts. As far as I know, sonic does not provide a TM and the inbuilt OpenEdge one is not usable with JTA. HTH. But perhaps it is more than you wanted to know. Regards, Gus > On Jan 8, 2018, at 8:10 PM, dbeavon wrote: > > Update from Progress Community > > dbeavon > > I really appreciate the pointers. I don't suppose there are any docs about this stuff? I know that each database has its own local transaction, but beyond that it is just a matter of guessing how OpenEdge might coordinate the committing of them. > > Having a consistent outcome is the goal and it sounds like the DataServer technology does a good job to try and make that happen. It reminds me a little bit of the procedures we use to send a message out to the Sonic MQ broker at the very *end* of an OpenEdge DBMS transaction. We procedurally try to make sure that it happens right before the ABL's "END. /*TRANSACTION*/. And we also put some code before the beginning of the transaction to try to protect against the possibility that someone will one day wrap an even larger transaction around the whole mess, thereby circumventing the efforts to send/commit the Sonic message as the very last step. > > (IE. you can roll back the database transaction, but you can't un-send a Sonic MQ message after you've manually committed it). > > I don't suppose Progress could incorporate this Sonic ABL "commit" operation, and make it a function of the DataServer product too? I have always wished that ABL would coordinate the committing of our Sonic messaging operations. It would make me sleep better at night. > > > View online > > > You received this notification because you subscribed to the forum. To unsubscribe from only this thread, go here. > > Flag this post as spam/abuse. > > regards, gus “less is my favorite editor. too bad it can’t actually edit files.” Chris Lesniewski-Laas

Continue reading...