Entries Tagged as 'transaction'

Online transaction processing

Online transaction processing, or OLTP, refers to a class of systems that facilitate and manage transaction-oriented applications, typically for data entry and retrieval transaction processing. The term is somewhat ambiguous; some understand a “transaction” in the context of computer or database transactions, while others (such as the Transaction Processing Performance Council) define it in terms of business or commercial transactions.http://www.tpc.org/ OLTP has also been used to refer to processing in which the system responds immediately to user requests. An automatic teller machine (ATM) for a bank is an example of a commercial transaction processing application.

The technology is used in a number of industries, including banking, airlines, mailorder, supermarkets, and manufacturing. Applications include electronic banking, order processing, employee time clock systems, e-commerce, and eTrading. The most widely used OLTP system is probably IBM’s CICS.


Requirements

Online transaction processing increasingly requires support for transactions that span a network and may include more than one company. For this reason, new OLTP software uses client/server processing and brokering software that allows transactions to run on different computer platforms in a network.

In large applications, efficient OLTP may depend on sophisticated transaction management software (such as CICS) and/or database optimization tactics to facilitate the processing of large numbers of concurrent updates to an OLTP-oriented database.

For even more demanding decentralized database systems, OLTP brokering programs can distribute transaction processing among multiple computers on a network. OLTP is often integrated into service-oriented architecture and Web services.


Benefits

Online Transaction Processing has two key benefits: simplicity and efficiency.

Reduced paper trails and the faster, more accurate forecasts for revenues and expenses are both examples of how OLTP makes things simpler for businesses. It also provides a concrete foundation for a stable organization because of the timely updating.
Another simplicity factor is that of allowing consumers the choice of how they want to pay, making it that much more enticing to make transactions.

OLTP is proven efficient because it vastly broadens the consumer base for an organization, the individual processes are faster, and it’s available 24/7.


Disadvantages

It is a great tool for any organization, but in using OLTP, there are a few things to be wary of: the security issues and economic costs.

One of the benefits of OLTP is also an attribute to a potential problem. The worldwide availability that this system provides to companies makes their databases that much more susceptible to intruders and hackers.

For B2B transactions, businesses must go offline to complete certain steps of an individual process, causing buyers and suppliers to miss out on some of the efficiency benefits that the system provides. As simple as OLTP is, the simplest disruption in the system has the potential to cause a great deal of problems, causing a waste of both time and money. Another economic cost is the potential for server failures. This can cause delays or even wipe out an immeasurable amount of data.


See also

  • Data mart
  • Data warehouse
  • OLAP
  • ETL
  • Transaction processing
  • Database transaction
  • Derby in-memory Java Database
  • IBM Customer Information Control System


Contrasted To

  • Batch Processing
  • Grid Computing


References


External links

  • IBM CICS official website
  • Transaction Processing Performance Council
  • Comparison of OLTP and OLAP at gnuLAMP
  • OLTP Schema
  • Transaction Processing: Concepts & Techniques Management
  • About Processing - in Hebrew - By Yoram Azrakיורם אזרק
  • Business Intelligence OLTP

Tags: Uncategorized by admin
No Comments »

Transaction Processing Management System

This article refers to the computer software. Please see TPMS for other uses

TPMS or Transaction Processing Management System is online transaction processing superstructure software from ICL (now Fujitsu Computer Services) that runs on their VME mainframe computers. The first versions were released in the mid-1970s and were sold worldwide.


Structure

The service runs in at least two Virtual Machines (VMs)

  • a Control VM (CVM), responsible for connecting, disconnecting terminals and routing messages
  • one or more Application VMs (AVMs), responsible for all application processing - receiving input messages and returning output messages.

Tags: Uncategorized by admin
No Comments »

Kernel Transaction Manager

Kernel Transaction Manager (KTM) is a component of the Windows operating system kernel in Windows Vista and Windows Server 2008 that enables applications to use atomic transactions on resources by making them available as kernel objects. The transaction engine, which operates in kernel mode, allows for transactions on both kernel mode and user mode resources, as well as among distributed resources. The Kernel Transaction Manager intends to make it easy for application developers to do a lot of error recovery, virtually transparently, with KTM acting as a transaction manager that transaction clients can plug into. Those transaction clients can be third-party clients that want to initiate transactions on resources that are managed by Transaction Resource Manager. The resource managers can also be third-party or built into the system.

KTM is used to implement Transactional NTFS (TxF) and Transactional Registry (TxR). KTM relies on the Common Log File System (CLFS) for its operation. CLFS is a high-performance, general-purpose log-file subsystem that dedicated user-mode and kernel-mode client applications can use and multiple clients can share to optimize log access and for data and event management and enable transactions.


External links

  • Kernel Transaction Manager on MSDN

Microsoft Transaction Server

Microsoft Transaction Server (or MTS) is a service component that enables support for transactions to be easily implemented in other applications.


Architecture

A basic MTS architecture is made up of:

  • The MTS Executive (mtxex.dll)
  • The Factory Wrappers and Context Wrappers for each component
  • The MTS Server Component
  • MTS clients
  • Auxiliary systems like:
    • COM runtime services
    • the Service Control Manager (SCM)
    • the Microsoft Distributed Transaction Coordinator (MS-DTC)
    • the Microsoft Message Queue (MSMQ)
    • the COM-Transaction Integrator (COM-TI)
    • etc.

COM components that run under the control of the MTS Executive are called MTS components. MTS components are all developed as in-proc DLLs and are implemented as one or more COM components. These components are deployed and run in the MTS Executive which manages them. As is usual with COM components, the object implementing the IClassFactory serves as a Factory Object to create new instances of these components.

MTS inserts a Factory Wrapper Object and an Object Wrapper between the actual MTS component that MTS manages, and its Client. Therefore, whenever the client makes a call to the MTS component, the Wrappers (Factory and Object) intercept the call and inject their own instance management algorithm called the Just In Time Activation (JITA) into the call. The wrapper then makes this call on the actual MTS component.

In addition to this, based on the information from the component’s deployment properties, transaction logic and security checks are also done in these wrapper objects.

For every MTS component, there also exists a Context Object which implements the IObjectContext interface. The Context Object maintains specific information about that component such as its transactional information, security information and deployment information. The MTS component calls into the Context Object through its IObjectContext interface.

In MTS, the actual middle-tier MTS component is not created until the call from a client reaches the container. Since the component is not running all the time, it does not use up a lot of system resources (even though an object wrapper and skeleton for the component are still hanging around for the component).

As soon as the call comes in from the client, the MTS wrapper process activates its Instance Management algorithm called JITA. The actual MTS component is created “Just In Time” to service the request from the wrapper. And when the request is serviced and the reply is sent back to the client, and the component either calls SetComplete()/SetAbort(), or the transaction that its part of ends, or the client calls Release() on the component, the actual MTS component is destroyed. In short, MTS is a stateless component model.

Generally, this is what happens on the Server when a client requests services from a typical MTS component:

  1. Acquire a database connection.
  2. Read the component’s state from either the Shared Property Manager or from an already existing object or from the client.
  3. Perform the business logic.
  4. Write the component’s changed state, if any, back to the database.
  5. Close and release the database connection.

It is thus possible to implement high latency resources as asynchronous resource pools, which should take advantage of the stateless JIT activation afforded by the middleware server.


External links and references

  • More details about MTS
  • Quick Tour of Microsoft Transaction Server
  • Interpreting the MTS events in the event log

Tags: Uncategorized by admin
No Comments »

Microsoft Transaction Server

Microsoft Transaction Server (or MTS) is a service component that enables support for transactions to be easily implemented in other applications.


Architecture

A basic MTS architecture is made up of:

  • The MTS Executive (mtxex.dll)
  • The Factory Wrappers and Context Wrappers for each component
  • The MTS Server Component
  • MTS clients
  • Auxiliary systems like:
    • COM runtime services
    • the Service Control Manager (SCM)
    • the Microsoft Distributed Transaction Coordinator (MS-DTC)
    • the Microsoft Message Queue (MSMQ)
    • the COM-Transaction Integrator (COM-TI)
    • etc.

COM components that run under the control of the MTS Executive are called MTS components. MTS components are all developed as in-proc DLLs and are implemented as one or more COM components. These components are deployed and run in the MTS Executive which manages them. As is usual with COM components, the object implementing the IClassFactory serves as a Factory Object to create new instances of these components.

MTS inserts a Factory Wrapper Object and an Object Wrapper between the actual MTS component that MTS manages, and its Client. Therefore, whenever the client makes a call to the MTS component, the Wrappers (Factory and Object) intercept the call and inject their own instance management algorithm called the Just In Time Activation (JITA) into the call. The wrapper then makes this call on the actual MTS component.

In addition to this, based on the information from the component’s deployment properties, transaction logic and security checks are also done in these wrapper objects.

For every MTS component, there also exists a Context Object which implements the IObjectContext interface. The Context Object maintains specific information about that component such as its transactional information, security information and deployment information. The MTS component calls into the Context Object through its IObjectContext interface.

In MTS, the actual middle-tier MTS component is not created until the call from a client reaches the container. Since the component is not running all the time, it does not use up a lot of system resources (even though an object wrapper and skeleton for the component are still hanging around for the component).

As soon as the call comes in from the client, the MTS wrapper process activates its Instance Management algorithm called JITA. The actual MTS component is created “Just In Time” to service the request from the wrapper. And when the request is serviced and the reply is sent back to the client, and the component either calls SetComplete()/SetAbort(), or the transaction that its part of ends, or the client calls Release() on the component, the actual MTS component is destroyed. In short, MTS is a stateless component model.

Generally, this is what happens on the Server when a client requests services from a typical MTS component:

  1. Acquire a database connection.
  2. Read the component’s state from either the Shared Property Manager or from an already existing object or from the client.
  3. Perform the business logic.
  4. Write the component’s changed state, if any, back to the database.
  5. Close and release the database connection.

It is thus possible to implement high latency resources as asynchronous resource pools, which should take advantage of the stateless JIT activation afforded by the middleware server.


External links and references

  • More details about MTS
  • Quick Tour of Microsoft Transaction Server
  • Interpreting the MTS events in the event log

Distributed transaction

A distributed transaction is an operations bundle, in which two or more network hosts are involved. Usually, hosts provide transactional resources, while the transaction manager is responsible for creating and managing a global transaction that encompasses all operations against such resources. Distributed transactions, as any other transactions, must have all four ACID properties, where atomicity guarantees all-or-nothing outcomes for the unit of work (operations bundle).

Open Group, a vendor consortium, proposed the X/Open Distributed Transaction Processing (DTP) Model, which became a de-facto standard for behavior of transaction model components.

Databases are common transactional resources and, often, transactions span a couple of such databases. In this case, a distributed transaction can be seen as a database transaction that must be synchronized (or provide ACID properties) among multiple participating databases which are distributed among different physical locations. The isolation property (the I of ACID) poses a special challenge for multi database transactions, since the (global) serializability property could be violated, even if each database provides it (see also global serializability). In practice most commercial database systems use strong strict two phase locking (SS2PL) for concurrency control, which ensures global serializability, if all the participating databases employ it. (see also commitment ordering for multidatabases.)

A common algorithm for ensuring correct completion of a distributed transaction is the two-phase commit. This algorithm is usually applied for updates able to commit in a short period of time, ranging from couple of milliseconds to couple of minutes.

There are also long-lived distributed transactions, for example a transaction to book a trip, which consists of booking a flight, a rental car and a hotel. Since booking the flight might take up to a day to get a confirmation, two-phase commit is not applicable here, it will lock the resources for this long. In this case more sophisticated techniques that involve multiple undo levels are used. The way you can undo the hotel booking by calling a desk and cancelling the reservation, a system can be designed to undo certain operations (unless they are irreversibly finished).

In practice, long-lived distributed transactions are implemented in systems based on Web Services. Usually these transactions utilize principles of Compensating Transactions, Optimism and Isolation Without Locking. X/Open standard does not cover long-lived DTP.

A couple of modern technologies, including Enterprise Java Beans (EJBs) and Microsoft Transaction Server (MTS) fully support distributed transaction standards.


References

Tags: Uncategorized by admin
No Comments »

Transaction

A transaction is an agreement, communication, or movement carried out between separate entities or objects, often involving the exchange of items of value, such as information, goods, services and money.

  • Financial transaction
  • Database transaction
  • Atomic transaction
  • Transaction processing
  • POS Transaction

Transaction may also refer to:

  • “Transaction,” an episode of the Death Note anime series, see List of Death Note episodes

Tags: Uncategorized by admin
No Comments »

Java Transaction API

The Java Transaction API (JTA) is one of the Java EE APIs allowing distributed transactions to be done across multiple XA resources. JTA is a specification developed under the Java Community Process as JSR 907. JTA provides for:

  • demarcation of transaction boundaries
  • X/Open XA API allowing resources to participate in transactions.


X/Open XA architecture

In the X/Open XA architecture, a transaction manager or transaction processing monitor (TP monitor), coordinates the transactions across multiple resources such as a database. Each resource has its own manager. The resource manager typically has its own API for manipulating the resource, for example the JDBC API used by relational databases. In addition, the resource manager allows a TP monitor to coordinate a distributed transaction between its own and other resource managers. Finally, there is the application which communicates with the TP monitor to begin, commit or rollback the transactions. The application also communicates with the individual resources using their own API to modify the resource.


JTA implementation of the X/Open XA architecture

The JTA API consists of classes in two Java packages:

The JTA is modelled on the X/Open XA architecture, but it defines two different APIs for demarcating transaction boundaries. It distinguishes between an application server such as an EJB server and an application component. It provides an interface, , that is used by the application server itself to begin, commit and rollback the transactions. It provides a different interface, the , that is used by general client code such as a servlet or an EJB to manage the transactions. Below is a diagram showing the JTA classes used for the X/Open XA interfaces:

The JTA architecture requires that each resource manager must implement the interface in order to be managed by the TP monitor. As stated previously, each resource will have its own specific API, for instance:

  • relational databases use JDBC
  • messaging services use JMS
  • generalized EIS (Enterprise Information System) resources use Java EE connector API.


Java Transaction API

The Java Transaction API consists of three elements: a high-level application
transaction demarcation interface, a high-level transaction manager interface intended
for an application server, and a standard Java mapping of the X/Open XA protocol
intended for a transactional resource manager.

UserTransaction Interface

The javax.transaction.UserTransaction interface provides the application the
ability to control transaction boundaries programmatically. This interface may be used
by Java client programs or EJB beans.

The UserTransaction.begin method starts a global transaction and associates the
transaction with the calling thread. The transaction-to-thread association is managed
transparently by the Transaction Manager.

Support for nested transactions is not required. The UserTransaction.begin method
throws the NotSupportedException when the calling thread is already associated
with a transaction and the transaction manager implementation does not support nested
transactions.

Transaction context propagation between application programs is provided by the
underlying transaction manager implementations on the client and server machines.
The transaction context format used for propagation is protocol dependent and must be
negotiated between the client and server hosts. For example, if the transaction manager
is an implementation of the JTS specification, it will use the transaction context
propagation format as specified in the CORBA OTS 1.1 specification. Transaction
propagation is transparent to application programs.


UserTransaction Support in EJB Server

UserTransaction Support in EJB Server

EJB servers are required to support the UserTransaction interface for use by EJB
beans with the TX_BEAN_MANAGED transaction attribute. The UserTransaction
interface is exposed to EJB components through the EJBContext interface using the
getUserTransaction method. Thus, an EJB application does not interface with the
Transaction Manager directly for transaction demarcation; instead, the EJB bean relies
on the EJB Server to provide support for all of its transaction work as defined in the
Enterprise JavaBeans Specification [5]. (The underlying interaction between the EJB
Server and the TM is transparent to the application.)
The code sample below illustrates the usage of UserTransaction by a
TX_BEAN_MANAGED EJB session bean:


// In the session bean’s setSessionContext method,
// store the bean context in an instance variable

this.ctx = sessionContext;

// somewhere else in the bean’s business logic
UserTransaction utx = ctx.getUserTransaction();

// start a transaction
utx.begin();

// Do work
// Commit it
utx.commit();


See also

  • Java transaction service


External links

  • [1] (jta-spec1 0 1)
  • JSR 907
  • Atomikos open source JTA implementation

Tags: Uncategorized by admin
No Comments »

Transaction time

Transaction time (TT) is a concept used in temporal databases. It denotes the time period during which a database fact is/was stored in the database.

In a database table transaction time is often represented by two extra table-columns StartTT and EndTT. The time interval is closed at its lower bound and open at its upper bound.

When the ending transaction time is unknown, it may be considered as “Until Closed”. Academic researchers and some RDBMS have represented “Until Closed” with the largest timestamp supported or the keyword “forever”. This convention is not technically precise.

  • See also Valid time

Tags: Uncategorized by admin
No Comments »

ALCS transaction monitor

ALCS is an application server that provides industrial-strength, online transaction management for mission-critical applications.

ALCS is a transaction processing monitor for the IBM System/3×0 and zSeries mainframes. It is a variant of TPF specially designed to provide all the benefits of TPF (very high speed, high volume, high availability transaction processing) but with the advantages such as easier integration into the data center offered by running on a standard IBM operating system platform.

Like TPF it is primarily used in the airline, hotel, and finance industries.

Whereas TPF runs as a standalone OS, ALCS is designed to run as an application on top of MVS/OS/390/z/OS. However, the API it provides to applications is very similar to that on TPF, so applications written for TPF can run on ALCS with minimal modifications: typically less modifications than are required to move from one release of TPF to another. ALCS 2.3.1 runs on OS/390 2.10 and z/OS.

Because it runs under standard IBM operating systems it can easily leverage other developments or enhancements on those platforms. For example to enable MQSeries for TPF required the porting, modification, and authoring of large volumes of code. To enable this on ALCS only an interface to the MQ product on z/OS needed to be written. And any enhancements made to MQ Series on z/OS by the MQ team are available without any additional work on the part of the ALCS development team. This also applies to TCP/IP, DB2, VTAM, and even basic disk i/o.


References

  • IBM: ALCS

Tags: Uncategorized by admin
No Comments »