|
•
|
Database and Embedded SQL You must know how to use database tools (such as Oracle sqlplus) to create, browse and manipulate database tables. You should be able to program in embedded SQL, and build applications with the database-provided embedded SQL to C++ pre-compiler (such as Oracle proc).
|
|
•
|
XML and DTD You must know how to use XML to describe XA configurations and you must understand Data Type Definition (DTD).
|
|
•
|
OMG and the Distributed Transaction Process (DTP) of X/Open You should know the DTP architecture concepts and terminology, as well as the client side implicit transaction programming model (using the transaction Current interface to start and end a transaction). You do not need to read through and understand the entire OMG OTS specification.
|
|
•
|
XA and database connection configuration You must be able to make minor modifications to XA and database configurations.
|
|
•
|
Client A CORBA application. See Client-initiated transaction (CIT) below for more information.
|
|
•
|
AP A CORBA client application that can initiate a transaction.
|
|
•
|
Server A CORBA server application that implements business logic. See RM and Server-initiated transaction (SIT) below for more information..
|
|
•
|
TM A Transaction Manager that coordinates global transactions. Typically, it is a stand-alone server process (such as a VisiTransact OTS server). In-proc TM is also supported in VisiTransact (ots.dll/so), but is not recommended.
|
|
•
|
RM A Resource Manager. In OMG OTS, RM usually refers to a database server. RM can also refer to an application server that uses SQL to access a database.
|
|
•
|
1PC One phase commit, involving a single RM, committed without a preparation stage.
|
|
•
|
2PC Two phase commit, involving multiple RMs, committed with a preparation stage.
|
|
•
|
Global transaction A transaction that can involve multiple RMs. Usually, but not necessarily, a global transaction needs to be coordinated by a TM and use a 2PC protocol to commit. See Local Transaction Optimization (LTO) below for more information. By default, all transactions described in this section are global transactions (initiated either by the client or the server).
|
|
•
|
Local transaction A transaction, which only involves one single RM, restricted in one thread of control, and not coordinated by TM.
|
|
•
|
Client-initiated transaction (CIT) Also known as a Client Demarcated Transaction, this term refers to a global transaction initiated and terminated by a client. Client-initiated transactions must be coordinated by a TM.
|
|
•
|
Server-initiated transaction (SIT) Also known as a Server Demarcated Transaction, this term refers to a global transaction initiated and terminated by a server PMT engine transparently when handling a client request. The boundary of this transaction is the given client request. The transaction starts before performing the business logic, and ends before replying to client. A server-initiated transaction is global, but not necessarily coordinated by a remote TM.
|
|
•
|
Local Transaction Optimization (LTO) A technique that allows a server to initiate and terminate a global transaction locally without involving a TM, if it only accesses one local RM (database). Server would only export a SIT to TM and evolve it into a true global transaction when server makes a forward call to a second RM (another transaction object outside the process). J2EE document presents a possible scenario of LTO, but not applicable to OTS implementation. Therefore, VisiTransact’s LTO uses a different technology to ensure it is OMG compliant, interoperable and applicable to other OTS implementations.
|
|
•
|
PMT POA Managed Transaction. A server side transaction and database integration engine. PMT separates and hides all database connection and transaction details from application business logic developers. With PMT, servant implementation business logic does not need to hardcode database connection and transaction logic within its implementation. Database connection and transaction control are independent of business logic, and can be configured and reconfigured during application assembling. With PMT, a given business logic implementation can involve both CIT and SIT. In addition, different operation signatures of a given object can be configured with different transaction attributes.
|
|
•
|
CosTransactions::Current A single object for client applications, in an implicit transaction model, to initiate and manipulate thread-specific global transaction. A server implementation can also use this object to retrieve thread-specific information about the global transaction it currently involves. The CosTransactions::Current can be retrieved from ORB using the resolve_initial_references() method.
|
|
•
|
PMT::Current: A single object for a server application to retrieve information about thread specific database connection and transaction arranged by PMT engine. The retrieved information, such as connection name, is necessary for the SQL AT clause. Other retrieved information is useful for PMT diagnosis. PMT::Current object instance can be retrieved from PMT::Current::instance().
|
|
•
|
XA: An API standardized by X/Open. XA API drivers (usually shared libraries) are provided by database vendors. PMT uses these drivers to manipulate database connections and transactions. With PMT, XA (as well as database connections and transactions) are transparent to application developers. It is the responsibility of the application assembler to configure XA correctly. See “XA resources configuration” for more information.
|
|
•
|
Session Manager (SM) A service used in previous releases. To use this service in this release, you must set the vbroker.its.its6xmode property to true. See “VisiTransact properties” for more information.
|
|
•
|
Resource Director (RD) A service used in previous releases. To use this service in this release, you must set the vbroker.its.its6xmode property to true. See “VisiTransact properties” for more information.
|
|
Figure 25
|
|
•
|
PMT_NotSupported
The propagation context is not copied to transaction current. POA neither joins the client’s transaction (T1), nor starts a server to initiate a new global transaction (T2). This is the default PMT attribute. This setting should be used for non-transactional methods to avoid the overhead of associating a current worker thread with a global transaction. |
|
•
|
PMT_Required
POA joins or propagates the client-initiated global transaction (T1), if the request from the client carries a global transaction context. Otherwise, POA initiates and ends a new global transaction (T2) for that request. This is the most useful PMT attribute setting for transactional methods. It ensures the business logic will always be performed with an XA connection and within a transaction. This attribute is referred as “AUTOTRAN” in classic TP products. |
|
•
|
PMT_Supports
POA joins or propagates the client-initiated global transaction (T1), if the request from client carries a global transaction context. Otherwise, if the request is not within a CIT, the POA does not start a transaction. When combined with a null XA resource (described in “XA resources configuration”), this PMT setting is typically used for transaction propagation. |
|
•
|
PMT_RequiresNew
POA does not join or propagate a global transaction of a client, but always initiates and ends a new global transaction (T2) on each client request. To improve performance, use this PMT setting for all business logic with only a perform read (query) operation on backend databases. |
|
•
|
PMT_Mandatory
POA always joins or propagates the global transactions of a client, if it is in a context. Otherwise, if the client did not start a transaction, POA raises an exception. |
|
•
|
PMT_Never
POA raises an exception if it is in a client transaction context. |
|
•
|
The oid file specifies the ID of the object this PMT attribute setting applies to. If the oid is an empty sequence (zero length), this attribute setting applies to all objects of this POA. See the list of dynamic rules for more details.
|
|
•
|
The method_name field specifies the request operation name this PMT attribute setting applies to. If method_name is set to *, this attribute setting will apply to all request operations sending to objects of this POA.
|
|
•
|
The mode field specifies the mode of this PMT mode attribute setting.
|
|
•
|
The xa_resource field specifies the name of a preconfigured XA resource to be associated. For more information, see “XA resources configuration”. If this field is an empty string or null, a PortableServer::POA::InvalidPolicy exception is raised on create_POA(). Literal null is a special reserved xa-resource name. This name cannot be used to name a physical XA resource in an XA resource descriptor, but can only be used as value of the xa_resource field of PMTAttr. When a request condition matches one of the given PMTAttr with xa_resource field equal to null, the PMT engine does not associate the request processing worker thread with any physical XA connection. Instead, the PMT engine only ensures that the associated OTS context is propagated if the servant implementation method makes a forward invocation to the next tier. See the oci example in the <installation_directory>\examples\vbroker\Transaction directory.
|
|
3
|
PMT attribute, its oid field exactly matches the request target’s object ID, and has a wildcard (*) in the method_name field, is applied.
|
|
5
|
PMT attribute, which has an empty oid field (indicating a wildcard) and a wildcard (*) in the method_name field, is applied.
|
|
•
|
A POA, which is PMT-enabled and has the name account_server_poa, is created.
|
|
•
|
Invocations on the target object with an ID of account_server_poa, an operation equal to withdraw is performed with the PMT_Required policy. It will either join the client-initiated transaction (T1), or, if the client did not initiate one, POA initiates a new global transaction (T2).
|
|
•
|
An xa-resource with the name account_storage is used by this transaction.
|
The name of the connection associated to the current work thread is returned by connectionName() of the current object. This name can be used to instruct an embedded SQL statement to use a specified connection, with either the AT <conn_name> clause or the SET CONNECTION <conn_name> statement, as shown in the following example:
void BankImpl::deposit(const char* id, float amount) {
EXEC SQL BEGIN DECLARE SECTION;
const char* account_id = id;
float deposit_amount = amount;
const char* conn = current->connectionName();
EXEC SQL END DECLARE SECTION;
EXEC SQL AT :conn UPDATE account_table
WHERE account_id = :account_id
SET balance = balance + :deposit_amount;
}
EXEC SQL BEGIN DECLARE SECTION;
const char* account_id = id;
float deposit_amount = amount;
const char* conn = current->connectionName();
EXEC SQL END DECLARE SECTION;
EXEC SQL AT :conn UPDATE account_table
WHERE account_id = :account_id
SET balance = balance + :deposit_amount;
}
The AT clause in the previous example is optional in some cases. For example, Oracle has the concept of default connection, which is the connection last opened by the thread-of-control. If an embedded SQL does not have the AT clause, Oracle uses the default connection. Other databases, such as Sybase, do not have the concept of default connection, and Borland recommends using the AT clause or SET CONNECTION statement with those databases.
|
•
|
const char* PMT::Current::resourceName() const:
Returns the XA resource name used by associated XA connection. See “XA resources configuration” for more information. |
|
•
|
const xid_t* PMT::Current::xid() const:
Returns the XID of the transaction associated with the current thread. If no transaction is associated, this method raises a CosTransactions::unavailable exception. |
|
•
|
int rmid() const;
Returns the XA resource manager ID of the XA connection associated with the current thread. If no XA connections and no transactions are associated, this method raises a CosTransactions::Unavailable exception. |
|
•
|
int attribute() const;
Returns the PMT attribute mode of the PMT attribute that matches or wildcard matches with the current {POA, oid, method-name} triplex. If PMT is not enabled on the POA, the return value is 0. |
|
•
|
int decision() const;
Returns a value 1 or 2, indicating the current thread is associated with a client or server-initiated transaction. If PMT is not enabled on the POA, the return value is 0. |
In VisiTransact, XA resources are also configured using an XML description named xa-resource-descriptor. An xa-resource-descriptor is the root element of an xa-resource-descriptor XML file, which typically has following structure:
|
•
|
name
Specifies a unique name for this xa-resource. This name is used by the PMT <transaction> element to decide which xa-resource the dispatched request should be associated with. The default value is default. |
|
•
|
xa-library
Specifies the library file name of the XA API library, provided by database vendor. If this attribute is left out, the engine will try to resolve the XA from the application executable module itself. |
|
•
|
xa-switch: Specifies the symbol of the xa_switch_t variable. For example, for Oracle XA, the symbol is xaosw, for Informix, the symbol is infx_xa_switch, and for DB2, the symbol is db2xa_switch.
|
|
•
|
xa-conn-scope: Specifies the scope of XA connection provided by the XA library. This depends on the XA API library that is used, and on the used XA open string (the info attribute in the <xa-connection> element).
|
|
•
|
name
Name of the connection. This name is returned from PMT::Current::connectName() method when the connection is associated with the thread. You must ensure that this name is consistent with the name assigned in the info string. |
|
•
|
info
The string passed to xa_open(). The information specified by this string is XA provider dependent. The following table shows typical setting templates: |
Using the information you provide, the PMT XA engine opens XA open connections. If the value of the xa-conn-scope attribute of <xa-resource> is process, VisiTransact opens one specified connection and associates it to one thread at a time. If the value of this attribute is thread, VisiTransact opens a connection per-work-thread when associating the given worker thread to a transaction.
|
•
|
name
The xa-resource’s alias name |
|
•
|
xa-resource
The actual xa-resource that this alias points to. |
|
•
|
The xa-resource specifies the xa-switch symbol xaosw, but not the xa-library file name. Therefore, VisiTransact resolves the xa switch within the current executable module, rather than from an external loaded library. This is a typical usage scenario because it is likely that the application has already linked with the client library of the database, which is likely to contain the needed XA API.
|
|
•
|
The xa-conn-scope is set to thread. This is consistent with the +Threads=true substring in the xa-connection’s info attribute. In this case, VisiTransact opens one dedicated XA connection per worker-thread when associating the thread with a transaction.
|
|
•
|
The xa-connection element omitted the name attribute, as well as the +DB=<name> substring in the info string. This is a typical usage scenario for an Oracle XA application under thread mode. The embedded SQL assumes the default connection. Applications do not need to use the AT clause.
|
|
•
|
An <xa-resource-alias> element is defined with the name default and points to the oracle <xa-resource> defined previously. Whenever a PMT <transaction> element is defined with the <xa-resource> name default, the referenced oracle xa-resource is used.
|
|
•
|
An additional <xa-resource-alias> element is defined with the name account-storage and points to the oracle <xa-resource> defined previously. Whenever a PMT <transaction> element is defined with the <xa-resource> name account-storage, the referenced oracle xa-resource is used.
|
If set to false, all VisiTransact PMT functions and optimizations are enabled. If set to true, PMT enhancements and optimizations are disabled, and the following deprecated features are enabled:
Specifies the XA-resource configuration file using this property. The default value is itsxadesc.xml.
The two-phase commit mechanism ensures that all nodes either commit or perform a rollback together. During the course of two-phase commit, if a failure occurs because of a network problem, database crash, or an unhandled software error, the transaction becomes in doubt and the resources in the database are locked and are not freed. To solve this problem VisiTransact comes with an RM recovery utility rmrecover (rmrecover.exe on Windows), along with automatic TM recovery.
|
•
|
|
1
|
|
•
|
For Windows: xa-library="oraclient9.dll"
|
|
•
|
For Unix: xa-library="libclntsh.so"
|