A Transaction Processing Monitor (TPmonitor) is a systems tool for configuration and management of usage of Computing Resources (terminals, printers, database resources) by users (people, online application programs, ?services) that are typically interactive in nature.

Processing of Transactions are important, but perhaps the Monitoring aspect of such type of software is the key point. Monitoring can include, but not limited to, logging, resource balancing, security management, etc. A TransactionProcessingMonitor has the primary role of coordination of services, much like an operating system, but does so at a higher level of granularity and can span multiple computing devices. -- OpenAuthor

''I'm no TransactionProcessingMonitor expert, but this seems vastly overly vague to me, given my past understanding of the subject. Surely something concerning transactions should appear centrally in this definition! The definition as it stands includes thousands of things that I know for a fact are not TPMs. Perhaps the problem is that the creator of this page is looking to learn the subject? Don't give definitions when you don't know the definition!''

Luckily the original author has not said he gave definitions, only descriptions.
----
I was hoping other people see fit to take on further description of this, however there had not been constructive additions.

I will therefore have to take these from RogerSessions, an ex IBM person turned MicroSoft guru turned ??, who authored a book on ComPlus. He called TPMonitors TPMs.

The book quoted the originator of this term as saying the '''T''' standed for Teleprocesing, not Transaction as it was originally coined. It became known later on as Transaction as it sounded much better. And it reflected the importance of management of transactions done by TPmonitors in a three tiered architecture.

Roger also has these to say:
* TPMs allow sharing of expensive database connections
* TPMs hides the interprocess communications details from programmers
* TPMs ''coordinate'' transaction processing
* TPMs ''check authorisation'' of processes

----
Examples of commonly used TPMonitors include:

	* CustomerInformationControlSystem, or CICS in short. Mostly found in IBM environments
	* TuxedoMonitor for the Unix environment
	* ApplicationServer''''''s using the JavaTwoEnterpriseEdition for the Unix environment
	* Encina for Unix (Is this in the same league as the other products?)
	* MicrosoftTransactionServer, or MTS. Now superseded by ComPlus which is also used in DotNet environments.
	* IbmIms 
----
The following Software Products are probably not classified as TransactionProcessingMonitors
	* ComPlus provides an environment and services to support a TransactionProcessingMonitor, but should not be viewed as a TransactionProcessingMonitor, which is a software product. A closer match would probably be the MTS component within a Windows 2000 Server.
	* A WebServer such as InternetInformationServer (IIS). A closer match would be the IIS server(s) running under the management services provided by a product such as M''''''icrosoftApplicationCenter.

----
Anyone interested in educating me in a comparative description of the product features listed above? -- DavidLiu
----
I agree with the RogerSessions definition. Here are a couple of other important stuff attached to TPM.

'''Sharing of resources'''

The first objective of a TransactionProcessingMonitor is to enable sharing of resources and the optimum use of those resources by the application.

This point is quite a key point. For a longer explanation, just consider some application that runs a fat client on the client workstation and owns its dedicated link to the database. This kind of application is generally referred to as a two tier application: one tier being the application  and the other tier the database. In this kind of model:
* You can run an application on a LAN with a limited number of users (up to several hundreds),
* You will need a big database machine with a lot of processes that are commonly doing nothing but wait for the user rollback buffers to commit,
* You can have programmers that will forget to commit or rollback transactions and so organize the possibility to lock for long periods of time some data in the database,
* You cannot scale very properly because you will reach a limit where the database machine cannot accept more database connections while guaranteeing correct response times.

The main idea of the TPM (on Unix-like platforms) is to introduce a layer of processes between the client side application and the database. Each TPM process will own one database connection. This process will be in charge of executing application code for a particular transaction or set of transactions. That means that the "TPM process" is made of two parts : one part being the monitor stack (TPM libraries) and the other being the application code linked together by the application developer. The link can build a process with one or several transactions in it. Unix-like TPM ususally support programming in CeeLanguage, CobolLanguage or CeePlusPlus.

The flow will be different in that model than in the two tier application model:
* The client side application invokes a "service" with data marshaled in the appropriate format; that means that the client application has some knowledge of:
** The TPM remote invocation language (probably a client middleware stack embedded into the client application),
** Or the knowledge of a "generic" way to call the TPM services through "standard" protocols (such as LU6.2, RPC, RMI/IIOP, proprietary formats, WSDL, etc.);
* The TPM chooses (commonly some kind of intelligent TPM agent) what process will handle the query (based on certain criteria such as addressing or load balancing concerns);
* The TPM processes unmarshals the message and calls back the application code;
* The application code does its stuff in the database and possibly commit or rollback the transaction;
* The TPM process can commit or rollback the transaction as well (when the TPM is configured to handle the database resource manager, the TPM commits or rollbacks);
* The answer is wrapped back in the appropriate format and sent back the the client application.

Right after the answer, the same TPM process can:
* Process another transaction (note that the TPM process is not suppose to "remember" something about the previous transaction - so the model is basically stateless);
* Get a clean context for the application code to run again.

'''Other TPM services'''

There are several other potential services provided by the TPM:
* Coordination of resource managers (typically a database engine, a transactional file engine, a queue system, coordinated one by one or all together in XA standard, etc.);
* Load-balancing and spawning of new TPM processes in case they are needed (dynamic workload management, process restart in case of core dump),
* Security access to services,
* Routing services (very often, the notion of "domain" is used),
* Wrapping and unwrapping respectively data messages into messages and the messages into data structures,
* Monitoring for operations,
* Protocol stack management,
* Quite often "Queue to queue" guaranteed delivery services,
* Error handling (such as process restart).

Some specific TPM can provided advanced services such as:
* Hot failover (even under high traffic) running in multi-nodes contexts,
* Secured and audit-able transaction journal (for applications where one single transaction shall not be lost).

'''About XA'''

Coordination of resource managers can be taken in charge by the TPM most commonly with the OpenGroup XA standard which enables two-phase commit (Unix-like environments). XA is not used a lot in the industry because it too often conflicts with the main business interest which is to always take the cash associated to the transaction to be performed (and not to rollback a full complex transaction because only one sub transaction failed).

Instead of XA, global data integrity in DistributedSystem''''''s is usually managed half by TPM services (such as enqueuing for later retry in case of ResponseTimeOut) and half by the application logic (in that case, every bouncing transaction should be specified correctly in case of RTO).

'''Design considerations'''

A TPM usually provides a kind of development framework for coders. This framework is usually quite restrictive both in the design of transactions (imposed callbacks, use of certain TPM APIs mandatory, restrictions in memory management, etc.) and in the building of the executables (requirement to build and link with the TPM libraries with some conventions). This usually makes the application specifically designed for a specific TPM.

In terms of transaction design, you may want to read the TransactionDesign page.

'''About off the shelf products'''

I would say there are three kinds of products:
* The mainframe products (such as CICS, IMS, TPF, GCOS7/TDS, etc.);
* The Unix-like products (such as Encina [''not sold anymore I think''] or Tuxedo);
* The mutithreaded "ApplicationServer" products (such as JEE or .Net servers).

The mainframe products are the best products ever. They were carefully designed and very deeply integrated into the OS, the database and the file system (in TPF, you don't even have a way to do batch processing, the full OS is the TPM - but this is a quite strange piece of stuff indeed). Most of the time, they are batch schedulers turned into transaction processing facilities. They coordinate remarkably the various resources managers. They are based on the fact that it costs very few to start and end a program under mainframes (initially those OS were made to do batch processing). So, each transaction will have its separate address space (separate process). This is good because that enables the TPM to consider a transaction dump as a standard behavior (in the old days, the IBM development manuals were pushing developers to dump transactions as a common way to do error management). So the TPM is managing lots of program instances running at the same time to perform transactions. This is the most reliable model.

The Unix-like products took the assumption that an idle process under Unix-like machines was costing nothing to the OS. Compared to mainframes, it was not possible to design a TPM based on start and stop of processes, those operations being too costly for Unix-like OS. So the TPM is generally built upon an administration process at least that runs TPM processes in which you have application code embedded. In case of a core, there is potentially a problem because the core puts at stake the possible TPM throughput. The administration process detects cores (or blocked processes) and start new instances of the dead process. This is a bit less reliable than under the mainframes.

The third kind of platforms is based on application code running in the same address space than the "TPM" (but is it still a TPM?) so in the same process. Transactions are ''threads''. That implies:
* You must have application developers able to code multi-thread-safe application code (that's rare);
* You accept the probability of application deadlocks on top of database deadlocks (which is not possible in multi-processes approaches);
* You accept that one aborting application thread terminates the whole TPM and all the pending transactions (which is quite bad for the database).

The third item on the list above is quite annoying. Mainframe of Unix-like TPMs abort one and only one transaction in case of a problem and not the full TPM. That is what's occurring with JEE and .Net platforms. The reliability of JEE and .Net TPM is questionable (even if the services provided by JEE and .Net software infrastructure are large).

'''Conclusion'''

Application servers such as JEE or .Net should be, for me, restricted to small transactional applications or to GUI related problems (and so stateful session handling). As soon as you want to develop something heavier, I would recommend you have a look to Unix-like TPMs. Mainframe TPMs are quite expensive and very proprietary but a lot of banks are using them extensively for decades.

The single-thread versus multi-thread thing is quite an important choice. Recently, Google designed the Chrome browser with a multi-processes approach for the same reasons TP monitors were designed: in case one "part" is failing, just one process will dump and the rest of the transactions will not suffer a negative effect on them, contrary to JEE or .Net approaches. For the same reasons Google cannot trust web developers, the TPM designers never really could trust application developers ;)

That's all folks. Hope that helps. -- OlivierRey 

----

CategoryTransactionProcessing