Does ABL have any features for coordinating a transaction that involves a local OE database and some remote resource as well? I'm wondering in particular about whether such features exist in the dataserver products (eg. for coordinating multiple dataservers, or coordinating a remote dataserver update with a local OE database update).
I'd also be very interested in coordinating a local OE database transaction with a messaging transaction (eg. JMS).
Currently we use JMS quite heavily in OE (using the "sonic" adapter). This involves quite a bit of developer effort to ensure that JMS sessions are always committed at the very end of a local OE database transaction. (This simulates an atomic transaction spanning both the OE database and the JMS resource).
But we will regularly "shoot ourselves in the foot" by reusing a procedure and wrapping it in a larger ABL transaction, without any consideration for the JMS activities. What happens after that is bad - we start sending messages out via JMS for as-of-yet uncommitted transactions. In the case of subsequent failure/rollback, the JMS message is long-gone and can't be "un-sent". This leads to a lot of problems, as you can imagine.
If OE ABL could coordinate the final JMS session commit (if/when the ABL transaction commits), then it would off-load a ton of finicky developer work..
Even if OE ABL would have a generic call-back mechanism to run some arbitrary piece of code during its commit phase, we could probably use something like that to send out any latent JMS messages.
Please let me know if there are any thoughts on transaction coordination involving remote resource managers. I think OE ABL has built some two-phase commit feature for enlisting two OE databases, but I don't know if they have ever included support for non-Progress databases or messaging products. (eg using an open standard like XA transactions)
Don't care about performance right now. Obviously I understand that certain tools and technologies have their own costs and trade-offs.