Databases Reference
In-Depth Information
No communications path is error free or fully
functional 100% of the time. Good communications design requires a posi-
tive feedback. The receiving system must tell the sending system that the
data it received was acceptable. This requirement is different from the
standard acknowledgement/negative acknowledgement (ACK/NAK) code
of a communications systems protocol. This feedback is done at the data
application level. It must be known not only that all the bits of the address
were received (ACK/NAK), but also that the customer number pointed to a
real existing customer.
Ensuring Positive Feedback.
Sometimes, the positive feedback and the back-flow communications
can be combined, thus reducing the network traffic. For example, a medical
master database that is adding a new patient sends a transaction giving the
demographic data. The satellite database reports back the local contract
number assigned to the patient, which is added to the master as an alter-
native key. Thus, both functions are served with a single transaction.
Like a public address system, transaction sys-
tems can suffer from feedback. Transactions are usually triggered when a
data field is updated. When this transaction arrives at the satellite data-
base, the associated data field is updated as well. If the satellite database
also reports changes in the data item, it would, of course, send a transac-
tion to report the change just made. The result is a feedback loop that caus-
es an endless chain of updates.
Preventing Feedback Loops.
To avoid feedback loops, the triggering mechanisms must be aware of
the source of the update. If the update came from the master database, the
satellite database must recognize that fact and prohibit the change from
being reported back to the master database.
Occasionally, more than one satellite database must
be updated with the same data from the master. It is good design to split
the transaction rather than have the master send two transactions. Mid-
dleware software is usually used in this case. The transaction is received
by the software and two (or more) transactions are forwarded to the sat-
ellite databases. The transactions may not have the same format (or even
the same communications protocol), even though they convey the same
information.
Split Transactions.
What happens if the satellite system sends a transaction and
the communications channel is down? An important feature of the network
should be that it is not possible to lose a transaction. Therefore, if the com-
munications channel is down, the software must wait and retry the trans-
action later. This recovery feature is inherent in some middleware and
some gateways. Regardless of where it exists or whether it was bought or
built, it must be present in the functional bridge in order to have a reliable
communications path.
Recovery.
Search WWH ::
Custom Search