Resolution:
Description:
============
How does TIBCO ActiveMatrix® Adapter for Database publisher work?

Environment:
===========
Platform: All Supported Windows/Linux/AIX/Solaris/HP-UX
All Databases
ADB adapter version: 5.x, 6.x

Resolution:
==========
THe following is how TIBCO ActiveMatrix® Adapter for Database publisher works (without Fault Tolearance and Load Balance enabled):

1). There are a total of three threads:
Main dispatcher thread - to handle timer/advisory events.
Polling thread (DB.INTERFACE) - to poll data from a database.
Publish/update thread (COMM.INTERFACE) - publish message and update the delivery status.

2). Adapter will create a total of three connections to a database:
adbPubPolling - for polling only.
adbPubUpdate - for updating delivery status from 'N' to 'P' for RVCM and 'N' to 'C' for other transport.
adbPubConfirm - for updating delivery status from 'P' to 'C' for RVCM, and no use for other transport.

3). These threads and connections are shared by all publisher services. No additional threads or connections are created when adding more publisher services.

4). Each thread uses its own connection. Connections will not be shared between threads.
Polling thread + adbPubPolling
Pub/update thread + adbPubUpdate/adbPubConfirm

5). The main dispatcher thread creates a polling event for each publisher service and puts them in an internal event queue (not RV or JMS) to notify the polling thread. When the polling thread is busy polling for a certain publisher, the event for that publisher will be discarded and not be put in the queue.

From the log we will see "Polling timer fired."

6).The polling thread reads polling events from the queue and does a polling for the publisher mentioned in the event. It will put the data in an internal data queue. When it finds there is pending messages for a certain publisher, it will discard the polling event for that publisher. The pending message is calculated with a counter. This is to avoid duplicated messages from being published.

From the log we will see " SELECT * FROM &ltpub table> WHERE ADB_L_DELIVERY_STATUS = 'N' ORDER BY ADB_SEQUENCE"

7). The Pub/Update thread reads data event from a data queue, publishes the message and updates the delivery status to 'P' for RVCM and 'C' for other transports. When it is blocked due to any error it will not continue.

From the log we will see "UPDATE &ltpub table> SET ADB_L_DELIVERY_STATUS = 'C' " (for transport other than RVCM)
Or
"UPDATE &ltpub table> SET ADB_L_DELIVERY_STATUS = 'P' " (for RVCM)

And message be published, like:
"Published message on &ltpub subject>"
"Publisher: data = "

** NOTE:  even though from the log, the adapter seems to update the status first and then publishes the message. It indeed first publishes the message and then updates the status.

**NOTE 2: The update thread needs to fetch table information the first time before it updates the status. If an error occurs, we will see the following error in the log:
"Get table: &ltpub table> metadata failed"

8). For RVCM, when all receivers confirm the message, the main dispatcher thread will receive an advisory "DELIVERY.COMPLETE" and then notify the Pub/Update thread. THe Pub/Update thread will then update the delivery status from 'P' to 'C'.

From the log we will see "Received ADVISORY _RV.INFO.RVCM.DELIVERY.COMPLETE"
and
"UPDATE &ltpub table> SET ADB_L_DELIVERY_STATUS = 'C' WHERE ADB_L_DELIVERY_STATUS = 'P' "

How does TIBCO ActiveMatrix® Adapter for Database publisher work?