What is the DB2 DRDA Resync Service?

Technorati Tags: Host Integration Server,DB2,DRDA,DTC,Transaction

This is something I knew a bit about, but not the whole story, so I had a talk with one of our developers, Vitaliy Golub, who very kindly explained to me (sometimes giving me a few kicks) how things work. Much of the below I gathered from him.

The DB2 DRDA Resync Service is installed when you install Host Integration Server 2009. The service  shows up as  the “HIS TCP/IP Resync Service”, but we prefer to call it the DRDA Resync Service. This service maintains

Host Integration Server, DB2, DRDA, DTC, Transaction

Technorati Tags: Host Integration Server,DB2,DRDA,DTC,Transaction

the transaction record for each DTC conversation. If you are not running distributed transactions, you can just ignore it, and for the rest of you, you may never even need it.

After Host Integration Server (or the ‘BizTalk Adapters for Host Systems’ is installed), another tool is then run to configure services, SQL databases, etc.  One of the options is for configuring Data Integration, and this is where the DRDA Resync Service is enabled when you select support for distributed transactions. The dialog appears  as such:

The Resync Port defaults to 50002. This is the port that the DRDA Resync Service will be listening on for incoming requests from the DB2 Servers. The next 2 settings, while adjustable, probably never need to be touched. . In fact, they could easily be lowered. If you only have 2 DB2 Servers, there is no need to have 50 connections and 4 worker threads sitting around doing nothing most of the time.

Next is the “Partner DB2 Resource Managers”. Here is where you enter in the names (or IP addresses) of your DB2 Servers which will be participating in distributed transactions. So, what happens if you don’t enter anything? Well, nothing 99.99998% of the time. This is the ‘rough’ estimate we have that this will never be used. The only time the resource manager will be contacted is IF the host has a problem with a transaction and need to know if to commit or rollback. This would happen very seldom. So, what happens if you enter nothing? Well, if the host ‘did’ need to find out what to do, it would attempt to contact the DRDA Resource manager. But, since it is not listed as a partner, the request would be rejected.  At that point the host system would need to determine to commit or rollback on its own. Depending on the host configuration, it could send this request indefinitely, until the worker threads on the host were actually ‘killed’. So, it is a good idea to enter in your DB2 servers here if you do plan to use distributed transactions.

The next option is the location of the SQL database where we will store information for the transactions.

So, what happens during a distributed transaction from say a DQP process such as SQL Query?

Say you are running a statement similar to this:

 SET XACT_ABORT ON
go
 BEGIN DISTRIBUTED TRAN
Go
INSERT INTO OPENQUERY (CHARLIEEW2K3DB2_PSS_CHARLIEE, 
    'SELECT * from CHARLIEE.MYAREA') 
    (AREAID, AREADESC,REGIONID) 
    values ('11111', 'Bellevue', 101)
COMMIT TRAN
GO
SET XACT_ABORT OFF

What happens here is that we will log an entry in the database to be used by the resource manager at the beginning of the transaction. We will pass a message to the DB2 host in a SYNCLOG message containing the IP address and port number of the HIS Server hosting the DRDA Resync Service, along with a transaction ID. If, for some reason,  the connection between HIS and the DB2 server was closed without a commit being sent, the host will communicate to our DRDA Resync Service to reconcile this in-doubt transaction.

After the commit, everything is ‘removed’. If everything flows properly, there should never be an entry here but for a few seconds (normally).

In a nutshell, the DRDA Resync Service is like the airbag in your car. It’s there, waiting, and you hope it is never utilized. But, if it is needed, it could save your life (transaction).