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
Hey There. I found your blog using msn. This is a very well written article. I’ll be sure to bookmark it and come back to read more of your useful info. Thanks for the post. I’ll definitely return.
ReplyDeleteWebdesign