Q2. Describe a TP monitor environment. How can a TP monitor stop an operating system being overwhelmed?

Answer:

According to Jeri Edwards', a TP Monitor is "an OS for transaction processing". TP monitor does mainly two things extremely well. They are Process management and Transaction management.
They were originally introduced to run classes of applications that could service hundreds and sometimes thousands of clients. TP Monitors provide an OS - on top of existing OS - that connects in real time these thousands of humans with a pool of shared server processes. (ProgrammerWorld.NET, 2008)
TP monitors provide the greatest performance advantage over both MQ and RPCs. Of course, it depends on what you're doing. Several features of TP monitors, such as BEA's Tuxedo, IBM's CICS, and Microsoft Transaction Server (MTS), enhance performance as well as provide the ultimate in scalability.
When it comes to support for many clients and a high transaction processing load, nothing beats a good TP monitor. TP monitors perform such tricks as using queued input buffer to protect against peaks in the workload. If the load increases, the engine is able to press on without having an effect on response time. TP monitors can also use priority scheduling to prioritize messages and support server threads, thus saving on the overhead of heavyweight processes. Also, the load balancing mechanisms of TP monitors make sure that no one process takes on an excessive load.
TP monitors also provide queuing, routing, and messaging features, which let distributed application developers bypass the TP monitor's transactional features. Here is where you can assign priorities to classes of messages letting the higher priority messages receive server resources first. (Linthicum, 1998)

TP monitor can stop the operating system being overwhelming. That is, the real performance value is the TP monitor's load-balancing feature. Load balancing lets TP monitors respond gracefully to a barrage of transactions. An example is end-of-the-month processing. As the demands increase, the transaction manager launches more server processes to handle the load and kills (stop) processes that are no longer required. What's more, the manager is able to spread the processing load among the processes as the transaction requests occur. (Linthicum, 1998)

Reference:

1. ProgrammerWorld.NET (2008). "Networking Interview Questions and Answers". ProgrammerWorld.NET, Retrieved from URL - http://faq.programmerworld.net/networking/networking-interview-questions-answers.html
2. Linthicum David S. (1998). "Application Architect". DBMS Online - Middleware Performance, Retrieved from URL - http://www.dbmsmag.com/9808d07.html
3. Schussel George (2009). "Client/Server: Past, Present and Future". Retrieved from URL - http://www.dciexpo.com/geos/dbsejava.htm