Implementation Comments
Transaction Based Systems:
Ø There is a
transaction control block associate with every active transaction that contains
information related to transaction type, identify and processing state
Ø Transactions are
usually not passed directly from one process to another but, are transferred
from process to process by means of centralized explicit centralized, common,
processing queues
Ø The next process for an active transaction is determined by
stored dispatch tables. This task is done by transaction
dispatcher
Ø The key points in
transactions life are recorded for different purposes using recovery and other
logs
Ø Self test support:
There are special transaction types and states for normal transactions whose
only purpose is to facilitate testing
Ø Transaction Flow Testing does not reveal anything that needs to be
worried. Bugs found here can be easily fixed
Ø The
decision in transaction flows are made by a processing module and the
dispatcher may direct the flows contained in the transaction control blocks or
in databases
Ø They
use certain control codes that actually constitute an internal language
Ø In such
case, all the transaction flows can be implemented as programs in internal
language
v The problem is that
these languages are often undeclared, undefined, unrecognized and poorly
documented
v The languages syntax,
semantics and processor have not been debugged
v Even if recognized,
self-consistency of the language is not checked
v The interpreter which
is usually be a single routine that processes the language ma have bugs
v The steps stored in
transaction control table may have bugs or may be corrupted
v Finally,
any transaction processing module can have bugs
Post a Comment
Post a Comment