Dr. SubrahManyam Allamaraju
© SubrahManyam Allamaraju 1999. All Rights Reserved.
.
All trademarks acknowledged.
Translation: 蝉 退 退
Translator's statement
(1) Copyright statement declared "written" without copyright holders may not copy this article in any form, this document is only published in the form of electronic version ", it is clear that the copyright statement does not limit the translation of electronic version and Communicate on the network.
(2) The translator does not do any form of guarantees. The translator does not have any rights to the translation and does not afford any obligation.
(3) Anyone should read the copyright statement carefully before any disposal of the translation (including but not limited to replication, propagation), and the translator is not responsible for the behavior of others.
Interpoxity: Figure 6 of the translator added to introduce the web page of ORBACUS OTS. The translator is a buryth, and the translation is inexpensive.
Original: http://www.subrahmanyam.com/articles/trahmn_nutsandboltsoftp.html Reprinted Declaration: Compliance with "Not copyright holder's written on any form to copy this article, this document is only published in the form of electronic version "And the reprinators do not have any powers in this article, and they are not responsible for any behavior that occurred in the reprint.
Introduction
Transaction management is one of the most important requirements for enterprise applications. In the field of trade, finance, and e-commerce, most of the large enterprise applications depends on the transaction function of delivering their business. In view of today's business's requirements for flexibility, in the distributed, deployment, and maintenance of enterprise-level distributed applications, transaction processing is one of the most complex parts.
This article introduces the following to the reader:
What is a business? What is ACID?
What is the main point of building a transaction application? Why is the transaction management middleware?
What is the typical system of the transaction application? What is the responsibility of various components in the system?
What concepts involved in the transaction system?
What are the standards and technologies in the field of transaction management?
This article is not specific to any product, which mains to maintain universality when describing various points and concepts. This article does not intend to compare the technical / standards of various transactions, just provide a discussion of this.
What is a transaction?
In order to complete the operation of data, enterprise applications often require concurrent data shared between multiple components. These applications should maintain data integrity under the following conditions (defined by the application's business rules):
Distributed access to a separate data resource, as well as
Access distributed resources from a separate application component.
In this case, a set of operations on the (distributed) resource may be required to be treated as a working unit (Unit). In a working unit, all parts of the operation successfully or failed and recovered. This problem is more complicated in the case:
Through a set of distributed, a component that accesses data from multiple resources is implemented, and / or
Some operations are executed in order or in parallel threads that require coordination and / or synchronization.
In all cases, it is required to apply the success or failure of a work unit. In the event of failure, all resources returns the data state to the previous state (for example, the state before the work unit begins).
Transaction Concepts and Transaction Manager (or a transaction service) Maintain data integrity in a work unit, which simplifies the construction of such an enterprise-level distributed application.
A business is a work unit with the following properties:
Atomicity: A transaction must be completely unspetructed or undo. In the case where an error occurs in any operation, the effect of all operations constituting the transaction must be revoked, and the data should be rolled back to the previous state.
Consisters: A transaction should protect all the unchanged properties defined on the data (such as integrity constraints). When a successful transaction is completed, the data should be in a consistent state. In other words, a transaction should switch the system from one consistent state to another. For example, in the case of a relational database, a consistent transaction will protect all integrity constraints on the data. Isolation: There may be multiple transactions in the same environment and execute, and each transaction should be independently executed. The effect of serial execution a series of transactions should be performed with concurrent execution. This requires two things:
During a transaction execution, the middle of the data (possibly inconsistent) status should not be exposed to all other transactions.
Two concurrent transactions should not operate the same data. The database management system usually uses a lock to implement this feature.
Durability: The effect of a completed transaction should be lasting.
These attributes are called the ACID attribute, and the guarantee is never incomplete. The data will never be inconsistent, and the concurrent transaction is independent, and the effect of a transaction is lasting. For a brief description of the distributed system, please see the fault and recovery in the transaction system.
Key points for building a transactional application
In order to lead the key points involved in the construction of a transaction application, consider a single order obtaining and order processing application, its system is displayed in Figure 1:
This application consists of two client components, and the order acquisition and order processing operation is implemented separately. These two operations constitute a work or transaction unit. Based on the product, order, inventory list and freight information. In this figure, read-only data access indicated by the pointed, and the continuous tip indication is indicated by modifying the transactional operation. Below is a transactional operation in this application:
Generate orders,
Update stock,
Generate freight records, and
Update the order status.
When implementing these operations as a transaction, you should be committed to the following points:
Applications should be in touch with transactional operations and operated databases. Therefore, the application should define a context to all transactions to include the above four operations.
Since the order acquisition and order processing is distributed over two components, the transaction context should be globally, and through the protocol conversion, it is propagated from the first component to the second.
The application should monitor the status of the transaction when the transaction occurs.
In order to maintain the atomicity, application components, and / or database servers, a mechanism should be implemented, and the changes to the database can be revoked under this mechanism, and the data consistency is not lost.
In order to isolate the concurrent transactions on shared data, the database server should track the data being operated and lock data during a transaction operation.
Applications should also maintain the association between database connections and transactions.
In order to achieve reliable locking, the application component should notify the database termination.
Transaction processing - system
I saw the main point of building a transactional application from my head, considering the construction of the same application in a transaction system displayed in Figure 2. Note that although there are a variety of possible systems, they will discuss in the following chapters, which represents the characteristics of the essential features shown in Figure 2.
`Figure 2: Transaction system
This system involves a resource manager for a transaction manager and each database (resource). These components are abstracted from the application component (order acquisition and order processing), and the responsibility of the transaction is shared. Various components of this system are discussed below.
Application component
Application component: responsibility
Establish and define a transaction
Communication transaction context
Operating data by resource manager
Application components are customers of transactional resources. They are programs for applying developers to implement business transactions.
With the help of the transaction manager, these components build global transactions, if needed, the transaction context, and operate over the range of these transactions. These components are not responsible for achieving the ACID attribute of protecting the transaction. But as part of the application logic, these components usually do to submit a decision to roll back a transaction.
Resource manager
Resource Manager: Responsibilities
Enabling resources to transaction servers
Participate in two phases submitting and recovery agreements
A resource manager is a component for managing persistent and stable data storage systems, and participates in two submission and recovery protocols with the same transaction manager.
A resource manager is typically a drive or a package on a stable storage system, an interface with operational data (to the application component), and in order to participate in two two-stage submission and recovery protocols coordinated by the transaction server. This component can also, direct or indirectly register resources to the Transaction Manager, so that transaction manager can track all resources involved in transactions. This process is called resource collection. In order to achieve two-stage submission and recovery protocol, the resource manager should implement the additional mechanism that may be restored.
The resource manager provides two sets of interfaces: a set of operations to the application component to connect and complete the data, and another set to the transaction manager to participate in two-stage submission and recovery protocol.
Transaction manager
Transaction manager: responsibility
Establish and maintain the transaction context
Maintain a transaction and a specific resource association
Initiate and command two-stage submission and recovery protocol
Synchronous calls to the application components before starting two-stage submission and recovery process
The transaction manager is a core component of a transaction environment. Its main responsibility is to establish a transaction when applying components, allowing resource collection and dismissal, and directs two-stage submission or recovery protocols with resource manager.
A typical transactional application starts a transaction by issuing a request to the transaction manager. In response, the Transaction Manager starts a transaction and associates it with the same call thread. The transaction manager also establishes a transaction context. All application components and / or thread sharing transactions in the transaction. The thread initially initiated the request for starting the transaction, or if the transaction manager is allowed, any other thread can eventually terminate the transaction by initiating commit or rollback requests.
Before a transaction is terminated, multiple components and / or threads can complete the transactional operations on multiple data known to the transaction manager. If the transaction manager is allowed, a transaction can be suspended or continued before the transaction is finally completed.
Once the application initiates a submission request, the Transaction Manager prepares all resources for a submission operation (via the vote vote for a vote), and is ready for all resources (ready) to initiate a submission or back to all resources. Ask for a roll.
The following sections discuss various concepts related to transaction processing.
Transaction processing - concept
Transaction
Specify a transaction called transaction default (Demarcation), complete the transaction from a global transaction, which is a way to mark a set of operations that make up a transaction.
The most commonly defined way is a thread that performs operations for transaction tags. This is called programming. This created transaction can be suspended by removing the marker and resumes execution by reversing the transaction of the recovery point from the hanging point to the recovery point.
The transaction is bound to end after a submission or a rollback request to the transaction manager. Submit requests Guide all the effects of all participating resource managers permanently record the operations in the transaction. Rollback requests to make the resource manager to undo the effect of all operations in the transaction.
An alternative programming is defined by the declaration. Component-based transaction processing systems such as Microsoft transaction servers, and application server-based transaction processing systems such as enterprise Java Beans specification support declarations. In this technique, the component is labeled as transactional at deployment. This suggests two things. First, the defined responsibilities are transferred from the application to the container of the accommodating member. To this end, this technology is also called the management container definition. Second, it is defined during the application construction period (static) extension to component deployment period (dynamics).
Transaction context and communication
Because multiple application components and resources are involved in a transaction, the status of transactions that occurred and maintained for transaction managers is necessary. This is usually done in the form of a transaction context.
The transaction context is an association between the transactional operations on the resource and the components of the calling operation. During a transaction execution, all the thread sharing transactions of all participating transactions are shared. So the transaction context is logically encapsulated (envelop) all operations that are completed on a transactional resource during a transaction. Transaction context usually transparently maintained by the underlying transaction manager.
Resource collection
Resource Collection is the process of reporting their participation in a transaction to the transaction manager. This process allows the transaction manager to track all resources participating in a transaction. Resource Manager uses these information to coordinate transactional work completed by the Explorer, and drive two-stage submission and recovery protocols. The transaction manager dispensing resources at the end of the transaction (after a submission or rollback). After that, the association between transactions and resources will not be maintained.
Two-stage submission
The protocol between this transaction manager and all resources to be a transaction is determined that all resource managers are submitted to transactions or they are endless (Abort). In this agreement, when the application requires the transaction, the Transaction Manager initiates a preparation request to all the resource managers involved. Each of these resources can sequentially send a response to indicate whether it is ready (ready). Transaction Manager initiates a submission request to all resource managers only when all resource managers are ready to be submitted. Otherwise, the transaction manager initiates a rolling request next to the transaction to be rolled back.
Transaction - Standards and Technology
X / Open distributed transaction model
The X / Open Distributed Transaction (DTP) model is a distributed processing model proposed by Open Group. Open Group is a vendor consortium. This model is a standard between most commercial manufacturers in the transaction and database field.
This model consists of four components:
Application: A transactional operation.
Resource Manager: The same discussion is the top.
Transaction Manager: Discussion with the above.
Communication Explorer: It is convenient for interoperability between different transaction managers in different business processing.
This model also defines the following interfaces:
TX interface: This is the interface between the application and transaction manager and is implemented by the Transaction Manager. This interface provides a transaction-defined service that allows applications to bind transactional operations into a global transaction. This interface consists of the following functions:
Table 1: TX interface for X / Open model
function
Features
TX_Open
Open a transaction manager and the associated group of resource manager.
TX_Close
Close a transaction manager and associated group of resource manager.
TX_BEGIN
Start a new transaction.
TX_ROLLBACK
Rollback transaction.
TX_COMMIT
Submit a transaction.
TX_set_commit_return
Submit a transaction. (Translation: Original)
TX_SET_TRANSACTION_CONTROL
Select between chain and non-chain mode. In the case of a chain transaction, the work is divided into a segment, and each fragment is under a flat (FLAT) transaction. Once a piece of work is completed, the submission or rollback of this fragment does not depend on the status of other segments.
TX_SET_TRANSACTION_TIMEOUT
Set a transaction timestone.
TX_INFO
Returns transaction information, such as its identifier, status of transaction, etc.
XA interface: This is a two-way interface between a resource manager and the transaction manager. This interface specifies two sets of functions. The first set is called the XA _ * () function, implemented by the resource manager and is used by the transaction manager.
Table 2: XA interface of transaction manager in the X / Open DTP model
function
Features
XA_Start
Guided an Explorer to associate a subsequent request for an application with a transaction identified by an identifier provided.
XA_END
End an resource manager is associated with a transaction.
Xa_prepare
The resource manager is prepared for the submission operation. The transaction manager is initiated and is the first phase of the two-stage submission operation.
XA_Commit
Submit a transactional operation. The transaction manager is initiated, which is the second phase of the two-stage submission operation.
XA_Recover
Retrieve a ready-to-list list, heuristic (Heuristical) submitted or healed rollback transaction.
Xa_forget
Forget the Heuristic transaction associated with a given transaction identifier.
The second set of functions called the AX_ * () function, implemented by the transaction manager, and is used by the resource manager.
Table 3: AX interface of the resource manager in the X / Open DTP model
function
Features
AX_REG
Dynamic to an transaction manager. AX_unreg
Dynamic from one transaction manager.
XA Interface: This interface is used to support global transactions through the Communication Explorer to span different transaction managers.
TXRPC interface: This interface provides portability of communication between different applications in a global transaction.
CRM-OSI TP: is an interface between a communication resource manager and an OSI transaction service service.
The X / Open DTP model is established in the industry. Some business transaction management products, like TxSeries / Encina (completely attached to IBM products), Tuxedo and Topend (BEA Systems products), as well as AT & T GIS support TX interface. Although Microsoft's Transaction Server does not support TX interfaces, it can also be interoperable with Databases of the XA. Similarly, most commercial database icons Oracle, Sybase, Informix, and Microsoft SQL Server, as well as the message middleware, such as IBM's MQSeries, and Microsoft's MSMQ Server provides an implementation of the XA interface.
OMG object transaction service
Object Services (OTS) is a distributed transaction processing service specified by the Object Management (OMG). This specification expands the CORBA model and defines a series of interfaces that cross (Across) multiple CORBA objects complete transaction processing.
The OTS model is based on the X / Open DTP model and provides the following enhancements:
The OTS model replaces the XA and TX interfaces in the function form to the CORBA IDL interface.
Various objects in this model communicate via CORBA method above IIOP.
OTS can be interoperable with the X / Open DTP model. An application that uses a transactional object can use the transaction manager's TX interface to perform transactions.
The OTS system consists of the following components:
Transaction Customer: A program or object that calls the operation on the transactional object.
Transactional Objects: Encapsulate or Reference (Refers to) CORBA objects for persistent data, and its behavior relies on whether to call it during a transaction.
Recoverable objects: A transactional object that directly maintains persistent data and participates in transaction protocols.
Transactional server: Collection of one or more transactional objects.
Recoverable Server: A collection of objects, at least one of them is recoverable.
Resource object: A resource object is an object in the transaction service to participate in two-stage submission and recovery protocols.
In addition to the usual transactional semantics, Corba OTS also provides the following:
Nested transactions: This allows an app to create a transaction embedded in an existing transaction. In this model, multiple subtransaction can be recursively embedded in a transaction. Sub-transactions can be submitted or rolled without submitting or rolling its parent business. However, the result of a submission operation must be submitted by all the ancestors of the transaction ("commitment). The main advantage of this model is that transactional operations can be controlled on a fine particle size. Application has an opportunity to correct or compensate for errors at sub-transaction levels without having to try to submit the entire parent.
Application Synchronization: Use the OTS synchronization protocol, after the start of the two-stage submission process, the specific object can be registered on the transaction service for the notification. This makes it possible to apply an object to synchronize the temporary (Transient) state and the data stored in persistent storage.
Figure 6: ORBACUS® OTS System (Translator Add)
Below is the principle of the CORBA OTS specification:
Table 4: CORBA OTS interface
interface
Responsibility
Current
Transaction defining (begin, commit, rollback, rollback_only, set_time_out)
Status of transactions (GET_STATUS)
The name of the transaction (GET_TRANSAction_NAME)
Transaction context (Get_Control)
TransactionFactory
Explicit business establishment
CONTROL
Explicit transaction context management
Terminator
Submit or roll back a transaction
Coordinator
Status of transaction (get_status, get_parent_status, get_top_level_status)
Information transaction (is_same_transaction, is_related_transaction, is_ancestor_transaction, is_descendant_transaction, is_top_level_transaction, hash_transaciton, hash_top_level_transaction, get_transaction_name, get_txcontext)
Resource collection (register_resource, register_subtrans_aware)
Registration of synchronous objects (Register_Synchronization)
Set the object to roll back (rollback_only)
Create sub-transaction (create_subtransaction)
Recoverycoordinator
Coordinate recovery in the case of failure (Replay_completion)
Resource
Participate in two phases submitting and recovery agreements (prepare, rollback, commit, commit_one_phase, forget)
SYNCHRONIZATION
Synchronization after the start of the two-stage submission (Before_completion, after_completion)
SubtransactionaWareresource
Submit or roll up a sub-transaction, is called by the service service (COMMIT_SUBTRANSACTION, ROLLBACK_SUBTRANSACTION)
TransactionalObject
A indicator (MARKER) interface for all transactional objects
The following products provide OTS implementation: Integrated Transaction Service (Inprise Product), ORBIXOTM (Iona Product), OTSARJUNA (ARJUNA SOLUTIONS LIMITED), and TPBROKER (Hitachi Software Products).
JTS and JTA
Java Transaction Services and Java Transaction APIs are the latest competitive participants in the field of distributed computing. As the initiator of the company Java, Sun Microsystems Inc. made a norm in 1999. (Translation: Official specification in December 8, 1999)
Figure 3: The initiation of Java transaction
JTS specifies the implementation of a Java transaction manager. This transaction manager supports JTA, and application servers can use it to build support for transactional Java applications. JTS's internal implementation of the OMG OTS 1.1 specification Java mapping. Java mappings are specified in two packages: org.omg.costransactions and org.omg.costsportability. Although JTS is a Java implementation of the OMG OTS 1.1 specification, JTA is still an interface to Xa and TX in X / Open DTP models in the X / Open DTP model.
JTA specifies a system for building a transactional application server and sets a series of interfaces for various components in this system. These components are: Application components, resource managers, and application servers, which are shown in Figure 3.
JTS provides a new system for transactional application servers and applications, while internally complying with the OMG OTS 1.1 interface. This allows compliance with the JTA applications to interoperate through standard IIOPs with other compliance with OTS 1.1.
As shown in Figure 3, in the Java transaction model, the Java application component can direct a transactional operation over the resources of JTA through JTS. JTS plays a thin layer on OTS. Applications can initiate global transactions to include other OTS transaction managers, or participate in a global transaction initiated by other transaction managers complying with OTS. See Java Transaction Services for more detailed narratives about JTS and JTA.
Microsoft Transaction Server
The Microsoft Transaction Server (MTS) is a component-based transaction server, which is based on Microsoft component object model (COM). The MTS programming model provides an interface to construct a transactional COM component, while the MTS operating environment provides a way to deploy and manage these components and management transactions. The MTS is used, and the work made by multiple COM components can be combined in a single transaction.
The MTS is a product and is not open-based specification in this chapter. Also note that although the MTS environment provides some other features, such as the resource buffer pool, Recycling, access control, this section focuses only on the transactionality of the MTS, and tries to put various transactions The concept of management is mapped to the MTS environment.
MTS system
The high-level MTS system is shown in Figure 4:
Figure 4: Microsoft Transaction Server
The MTS environment consists of the following parts:
MTS Runtime Environment: It is an instance of the MTS component execution and managed environments. The MTS runtime environment provides deployment and management of MTS components. It has the following characteristics:
Distributed transaction management
Atomic management of process and thread
Object (establishment, buffering and reuse) management
Distributed security services for controlled objects
MTS Explorer: This is a graphical user interface-driven tool for deploying and managing MTS components in the MTS operating environment. MTS Explorer is also used to monitor transactions through a distributed transaction coordinator.
Distributed Transaction Coordinator (DTC): DTC is the MTS transaction manager.
MTS API: MTS API (in Microsoft Visual Basic, Microsoft Visual C , and Microsoft Visual J ) provides specific interfaces and specific specific classes for construction transaction components.
Resource Distributor: A MTS resource distributor represents the MTS application to manage non-lasting shared data. MTS offers two resource distributors:
ODBC resource distributor: ODBC resource distributor is essentially an ODBC drive manager and has the following additional features:
Manage the buffer pool that follows the database of the ODBC, including the recycling and reuse of the connection.
Collection and disappointment of database connections on the MTS context object.
Shared Properties Manager: MTS Shared Properties Manager Management Application Specific Process (a pair of name-value) and provides information on synchronization.
Explorer: For a resource manager involved in the MTS transaction, it must support one of the following protocols:
OLE transaction: This is a two-phase submission protocol based on CoM, and the resource manager uses it to participate in transactions coordinated by DTC.
X / Open DTP XA Protocol: For this protocol, MTS requires an OLE transaction to the XA mapper (MAPPER). This map is provided in the MTS SDK.
MTS object and transaction context
An MTS object is an instance of an MTS component (a component is deployed on the MTS and manages MTS). For each MTS object, MTS establishes and maintains an ObjectContext, which provides a context for a MTS object. The context object also maintains information about the transaction context. Resource distributors and DTCs can access this transaction context information for transaction, resource collection, dismissal, two-stage submission, etc. Note that in the MTS, the transaction context information is maintained for each MTS object instead of maintaining a single transaction context object for all objects involved in a transaction. Transaction
Each MTS object can participate in the result of the determination of a transaction by calling a method of the ObjectContext object (OUTCOME):
SetComplete: Inform MTS, the object has successfully completed its work, and its work can be submitted.
Setabort: Inform MTS, the work of the object cannot be submitted.
EnableCommit: The work of the object is not necessary, but its transaction work can be submitted in the current form.
DisableCommit: Inform MTS, the work of the object cannot be submitted in the current form.
Transaction
MTS simultaneously allows transactions to program definition and declarations. The declaration is mandatory for deploying components on the MTS. In addition, MTS customers can also initiate and end transactions.
Declaration Definition: Relying on a transaction attribute (Property) of an MTS component, the MTS represents an automated start of a transaction. It is possible to have the following transaction attributes (can be set during deployment):
Requirements: The instance of the component is always executed in the context of a transaction. It is desired to call (call) the object is executed in the context of a transaction.
Require new transactions: The instance of the component must be implemented in their own affairs, without considering whether the call object has started a transaction.
Support transaction: An instance of the component can be executed within the range of the transaction (if any) of the object. This implies that the component is the safety of affairs.
Does not support transactions: The instance of the component is not executed within the range of any transaction. The MTS does not associate such a work together with any business.
Programming Definition: MTS customers can define transactions with the transactionContext object. A customer can start a transaction by establishing an instance of the TransactionContext object and ends the transaction by calling the COMMIT or Abort method of this object. All MTS objects established within these boundies of these TransactionContext objects will be executed under the same transaction. (Unless the component is set to require a new transaction or do not support transactions). The MTS implied maintenance TRANSACTIONCONTEXT objects and transactions are associated.
Resource collection
MTS performs an automatic resource collection. When an MTS object requires a resource connection to a resource connection, the resource distributter gets the transaction context of the call object and is used to register.
The Economic MTS can only be obtained on the Microsoft Windows platform, MTS can interoperate with resource manager followed by the XA protocol, and such resource managers operated on a non-Windows platform can participate in transactions coordinated by DTC.
For more information on MTS, please refer to MSDN LIBRARY. Refer to MTS FAQ to get a quick and detailed feature compilation of MTS and other competitive technology.
Java Beans
Enterprise Java Beans (EJB) is a technical specification from Sun Microsystems INC. It specifies a framework for building components-based distributed applications. In the past six months, the application server that meets this technology has emerged from different manufacturers, and the norm is currently constantly improving by Sun Microsystems Inc. (Translation: The official specification is launched on March 24, 1998).
As an application server framework, EJB servers are committed to transaction, resource buffer pool, security, thread, persistence, remote access, life cycle, etc. But with MTS, this section focuses only on the distributed transaction model of the EJB framework. The EJB framework specifies the construction, deployment, and excitation of components called Enterprise Beans. EJB specification divides Enterprise Beans into two categories: entity (Entity) and task (session) Beans. Entity Beans Abstract is a persistent domain data, task Beans provides a specific application logic task. Two types of Beans are maintained in things called the container. A container offers an ENTERPRISE Beans.
Figure 5 shows a simplified system that follows the EJB application server. Only in the figure shows the essential interaction between the components of the system.
Figure 5: Transactions in the EJB application server
A Enterprise Bean is specified by two interfaces: HOME interface and Remote interface. HOME interface specifies how to create and find a bean. Through this interface, a customer or other bean can get a reference to a bean residing in a container on an EJB server. Remote Specifies how to be applied to an entity or task bean.
Customers can get references to the Home interface of Enterprise Beans through the Java Naming and Directory Interface: JAVA Naming and Directory Interface: JNDI. An EJB server should provide a JNDI implementation for any naming and directory server. By using this reference to the HOME interface, a customer can get a reference to the Remote interface. Customers can then access the methods specified in this Remote interface. The EJB specification specifies the Java remote method inspiring the protocol of the application layer excited by the remote method. However, an implementation can use IIOP as a wire-level protocol.
In Figure 5, the customer first obtains a reference to the HOME interface, then a reference to an instance of Bean A is obtained by the Home interface. An instance of Bean A obtains a reference to an instance of Bean B and calls the method on which it applies the same process.
EJB transaction model
The EJB framework does not specify transaction management specific to any transaction service (such as JTS) or protocol. However, the specification requires the JTS's Javax.Transaction.UserTransAction interface to Enterprise Bean. The following paragraphs discussed the privileges defined to request this interface.
Similar to the MTS, the EJB framework provides a declaration of a transaction. The container specifies the attribute (attribute) that is deployed in a container, which is defined.
The following properties determine how to create a transaction.
Does not support: The container is not called bean in a global context.
Requirements: The container calls beans in a global context. If the call thread already has a associated transaction context, the container calls the bean in the same transaction. Otherwise, the container creates a new transaction and calls Bean in this transaction.
Support: bean is a business. If the customer calls beans in a transaction, Bean is also called in the same transaction. Otherwise, beans are not called in a transaction context.
Require new: whether the customer is associated with a transaction, the container calls beans in a new transaction.
Force: The container must call beans in a transaction. The container should start a transaction before calling any methods on the bean.
Transaction
The EJB framework supports three types of transactions.
The declaration defines: This is also called the definition of container management. The container defines the representative bean defining the transaction. Specify the required properties when deploying beans on an EJB server. Bean can use the javax.ejb.ejbcontext.setrollbackonly () method to mark the transaction. BEAN management definition: This is similar to the definition of customer management.
Definition of customer management: Java customers can use the Javax.Transaction.UsertransAction interface to program the defined transaction.
Resource collection
EJB automatically performs resource collection. The EJB container is automatically connected to the EJB-Aware Explorer when a BEAN is connected.
Application synchronization
The EJB specification provides the Javax.ejb.Sessionsynchronization interface for the application synchronization. When it is implemented by a bean, the container calls the AfterBegin, BeforeCompletion, and AfterCompletion methods for applications during the two-stage commit period.
There are currently some vendors to provide applications that follow the EJB 1.0 specification. Such products include the Gemstone / J, Sun Microsystems Inc. of the Wea Systems Inc., NetDynamics, Oracle Corporation Oracle Application Server, and Pestier for EJB, and Persistence Software Inc.. See EJB Directory to get a list of EJB application servers and EJB-Aware databases. The norm is currently undergoing a larger complete maintenance, and the new standard product is expected to be launched in the end of 1999 or early 2000 (translation: Norms 1.1 in December 17, 1999. The current specification is 2.0).
Overall, the EJB framework provides features that are extremely similar to MTS. Both techniques allow for components-based transactional distributed applications, and abstract transaction definitions from the application components.
in conclusion
Transaction has always been complex and important. However, with the arrival of MTS and EJB, transaction processing also seized the interests and attention of developers and IT organizations. This is not unreasonable. These fresh technology simplify distributed transaction management and supply fuel for three important development:
Distributed calculation: Two competition distributed computing models (CORBA and COM / DCOM) simplified distributed calculations.
Based on component development: Based on the above-mentioned interface-based example (PARADIGM), and components based on components are reality.
Object-oriented: Design mode and framework promotes the maturity of object-oriented programming, object-oriented to achieve these technologies.
In addition, these technologies are also dedicated to scalability and robustness of today's application requirements.
The goal of this article is to focus on the points and concepts involved in distributed transaction management. This article cannot fully cover all detailed details of these underlying technologies. At the same time, this article does not intend to compare the technology, but attempts to map multiple concepts to each technology. Only NUTS and BOLTS are discussed instead of how to build them and use them to build what machines.
