DTC (Distributed Transaction Controller) info and Issues

[Don Martin]

I’ve just finished building a web service call sequence in Cloverleaf using the DTC flow and there are several things I like about the DTC protocol.  The idea of a static transaction ID for all messages tied to the DTC flow makes it easy to store, track, and retrieve data as it passes through a series of threads.  I also like having the ability to use a rollback proc at any point in the sequence to generate a single error DB entry for failure at any point in the transaction.

However, there are a couple of issues that I’ll post here for general info for anyone new to DTC, and also in hopes that the Infor dev team can take a look at addressing them.  Or maybe someone will find something I didn’t set up correctly that would fix the issues I’m having!

Issue #1 : Every time a DTC thread is saved, if a raw reply route doesn’t already exist for any threads that are being used with the DTCSEND disposition, a new raw route is created.  That’s fine if you only intend to use raw reply routes for the replies sent back to the DTC thread, but if you are using an xlate reply route, this will cause a problem – you’ll need to manually delete the raw reply route from each thread using an xlate reply route every time you save changes to the DTC thread.

Issue #2:  The DTC database TCL APIs don’t work as advertised.  The keyspace created is created with threadname_xlate^xid ($HciConnName^$xid).  So you don’t have a DTC keyspace for the specific transaction.  You can get around this by using the staging DB TCL API instead and saving data using the xid as the keyspace.  In other words, use stageset and stageget instead of dtcset and dtcget if you want to store a message for use by any step in the DTC flow.

Topic