|
|
This topic includes the following sections:
Note: This topic describes using the C++ interface to the CORBAservices Object Transaction service. For a complete description of all the transaction features available in the WLE product and instructions for implementing the transaction features, see Using Transactions in the WebLogic Enterprise online documentation.
One of the most fundamental features of the WLE product is transaction management. Transactions are a means to guarantee that database transactions are completed accurately and that they take on all the ACID properties (atomicity, consistency, isolation, and durability) of a high-performance transaction. The WLE system protects the integrity of your transactions by providing a complete infrastructure for ensuring that database updates are done accurately, even across a variety of resource managers.
The WLE system includes the following:
Overview of the Transaction Service
The WLE product provides a C++ interface to the OTS and a Java interface to the OTS via the JTS. The JTS is the Sun Microsystems, Inc. Java interface for transaction services, and is based on the OTS. The OTS and the JTS are accessed through the TransactionCurrent environmental object. For information about using the TransactionCurrent environmental object, see Programming Reference in the WebLogic Enterprise online documentation.
Only the application-level demarcation interface (javax.transaction.UserTransaction ) is supported. For information about JTA, refer to the following:
OTS, JTS, and JTA each provide the following support for your business transactions:
Figure 6-1 illustrates how transactions work in a WLE CORBA application.
A basic transaction works in the following way:
What Happens During a Transaction
Figure 6-1 How Transactions Work in a WLE CORBA Application
In the Transactions sample application, the operation of registering for courses is executed within the scope of a transaction. The transaction model used in the Transactions sample application is a combination of the conversational model and the model in which a single client invocation invokes multiple individual operations on a database.
The Transactions sample application works in the following way:
Figure 6-2 illustrates how the Transactions sample application works.
The Transactions sample application shows two ways in which a transaction can be rolled back:
Note: For information about how transactions are implemented in WLE CORBA Java applications, see the description of the XA Bankapp sample application in Using Transactions in the WebLogic Enterprise online documentation.
This topic describes the development steps for writing a WLE CORBA application that includes transactions. Table 6-1 lists the development steps.
Development Steps
Table 6-1 Development Steps for WLE CORBA Applications That Have Transactions
Step |
Description |
---|---|
Write the OMG IDL code for the transactional CORBA interface.
|
|
The Transactions sample application is used to demonstrate these development steps. The source files for the Transactions sample application are located in the \samples\corba\university
directory of the WLE software. For information about building and running the Transactions sample application, see Samples in the WebLogic Enterprise online documentation.
The XA Bankapp sample application demonstrates how to use transactions in Java WLE CORBA applications. The source files for the XA Bankapp sample application are located in the \samples\corba\bankapp_java
directory of the WLE software. For information about building and running the XA Bankapp sample application, see Samples in the WebLogic Enterprise online documentation.
You need to specify interfaces involved in transactions in Object Management Group (OMG) Interface Definition Language (IDL) just as you would any other CORBA interface. You must also specify any user exceptions that may occur from using the interface.
For the Transactions sample application, you would define in OMG IDL the Registrar
interface and the register_for_courses()
operation. The register_for_courses()
operation has a parameter, NotRegisteredList,
which returns to the client application the list of courses for which registration failed. If the value of NotRegisteredList
is empty, the client application commits the transaction. You also need to define the TooManyCredits
user exception.
Listing 6-1 includes the OMG IDL code for the Transactions sample application.
Listing 6-1
OMG IDL Code for the Transactions Sample Application
#pragma prefix "beasys.com" { //Classes restricted to same time block on all scheduled days, struct ClassSchedule struct CourseDetails struct StudentDetails enum NotRegisteredReason struct NotRegistered exception TooManyCredits //The Registrar interface is the main interface that allows CourseDetailsList get_courses_details(in CourseNumberList }; // The RegistrarFactory interface finds Registrar interfaces. interface RegistrarFactory Transaction policies are used on a per-interface basis. During design, it is decided which interfaces within a WLE application will handle transactions. The transaction policies are:
Step 1: Write the OMG IDL code.
module UniversityT
typedef unsigned long CourseNumber;
typedef sequence<CourseNumber> CourseNumberList;
struct CourseSynopsis
{
CourseNumber course_number;
string title;
};
typedef sequence<CourseSynopsis> CourseSynopsisList;
interface CourseSynopsisEnumerator
{
//Returns a list of length 0 if there are no more entries
CourseSynopsisList get_next_n(
in unsigned long number_to_get, // 0 = return all
out unsigned long number_remaining
);
void destroy();
};
typedef unsigned short Days;
const Days MONDAY = 1;
const Days TUESDAY = 2;
const Days WEDNESDAY = 4;
const Days THURSDAY = 8;
const Days FRIDAY = 16;
//starting on the hour
{
Days class_days; // bitmask of days
unsigned short start_hour; // whole hours in military time
unsigned short duration; // minutes
};
{
CourseNumber course_number;
double cost;
unsigned short number_of_credits;
ClassSchedule class_schedule;
unsigned short number_of_seats;
string title;
string professor;
string description;
};
typedef sequence<CourseDetails> CourseDetailsList;
typedef unsigned long StudentId;
{
StudentId student_id;
string name;
CourseDetailsList registered_courses;
};
{
AlreadyRegistered,
NoSuchCourse
};
{
CourseNumber course_number;
NotRegisteredReason not_registered_reason;
};
typedef sequence<NotRegistered> NotRegisteredList;
{
unsigned short maximum_credits;
};
//students to access the database.
interface Registrar
{
CourseSynopsisList
get_courses_synopsis(
in string search_criteria,
in unsigned long number_to_get,
out unsigned long number_remaining,
out CourseSynopsisEnumerator rest
);
courses);
StudentDetails get_student_details(in StudentId student);
NotRegisteredList register_for_courses(
in StudentId student,
in CourseNumberList courses
) raises (
TooManyCredits
);
{
Registrar find_registrar(
);
}; Step 2: Define transaction policies for the interfaces.
Transaction Policy |
Description |
---|---|
In the Transactions sample application, the transaction policy of the Registrar
interface is set to always
.
The CORBA client application needs code that performs the following tasks:
Step 3: Write the CORBA client application.
Listing 6-2 illustrates the portion of the CORBA C++ client applications in the Transactions sample application that illustrates the development steps for transactions.
For an example of a CORBA Java client application that uses transactions, see the XA Bankapp sample application in Guide to the Java Sample Applications in the WebLogic Enterprise online documentation.
Listing 6-2 Transactions Code for CORBA C++ Client Applications
CORBA::Object_var var_transaction_current_oref =
Bootstrap.resolve_initial_references("TransactionCurrent");
CosTransactions::Current_var transaction_current_oref=
CosTransactions::Current::_narrow(var_transaction_current_oref.in());
//Begin the transaction
var_transaction_current_oref->begin();
try {
//Perform the operation inside the transaction
pointer_Registar_ref->register_for_courses(student_id, course_number_list);
...
//If operation executes with no errors, commit the transaction:
CORBA::Boolean report_heuristics = CORBA_TRUE;
var_transaction_current_ref->commit(report_heuristics);
}
catch (...) {
//If the operation has problems executing, rollback the
//transaction. Then throw the original exception again.
//If the rollback fails,ignore the exception and throw the
//original exception again.
try {
var_transaction_current_ref->rollback();
}
catch (...) {
TP::userlog("rollback failed");
}
throw;
}
When using transactions in server applications, you need to write methods that implement the interface's operations. In the Transactions sample application, you would write a method implementation for the register_for_courses() operation.
If your WLE CORBA application uses a database, you need to include code in the server application that opens and closes an XA resource manager. These operations are included in the Server::initialize() and Server::release() operations of the Server object.
Listing 6-3 shows the portion of the code for the Server object in the Transactions sample application that opens and closes the XA resource manager.
Note: For a complete example of a C++ server application that implements transactions, see the Transactions sample application in Using Transactions in the WebLogic Enterprise online documentation.
For an example of a Java server application that implements transactions, see the description of the XA Bankapp sample application in Using Transactions in the WebLogic Enterprise online documentation.
Listing 6-3 C++ Server Object in Transactions Sample Application
CORBA::Boolean Server::initialize(int argc, char* argv[])
{
TRACE_METHOD("Server::initialize");
try {
open_database();
begin_transactional();
register_fact();
return CORBA_TRUE;
}
catch (CORBA::Exception& e) {
LOG("CORBA exception : " <<e);
}
catch (SamplesDBException& e) {
LOG("Can't connect to database");
}
catch (...) {
LOG("Unexpected exception");
}
cleanup();
return CORBA_FALSE;
}
void Server::release()
{
TRACE_METHOD("Server::release");
cleanup();
}
static void cleanup()
{
unregister_factory();
end_transactional();
close_database();
}
//Utilities to manage transaction resource manager
CORBA::Boolean s_became_transactional = CORBA_FALSE;
static void begin_transactional()
{
TP::open_xa_rm();
s_became_transactional = CORBA_TRUE;
}
static void end_transactional()
{
if(!s_became_transactional){
return//cleanup not necessary
}
try {
TP::close_xa_rm ();
}
catch (CORBA::Exception& e) {
LOG("CORBA Exception : " << e);
}
catch (...) {
LOG("unexpected exception");
}
s_became_transactional = CORBA_FALSE;
}
You need to add the following information to the configuration file for a transactional WLE CORBA application.
Listing 6-4 includes the portions of the configuration file that define this information for the Transactions sample application.
Listing 6-4
Configuration File for Transactions Sample Application
*RESOURCES *MACHINES *GROUPS OPENINFO = "ORACLE_XA:Oracle_XA+SqlNet=ORCL+Acc=P *SERVERS TMFFNAME TMFFNAME TMFFNAME TMIFRSVR ISL *SERVICES For information about the transaction log and defining parameters in the Configuration file, see Creating a Configuration File in the WebLogic Enterprise online documentation.
IPCKEY 55432
DOMAINID university
MASTER SITE1
MODEL SHM
LDBAL N
SECURITY APP_PW
BLOTTO
LMID = SITE1
APPDIR = C:\TRANSACTION_SAMPLE
TUXCONFIG=C:\TRANSACTION_SAMPLE\tuxconfig
TLOGDEVICE=C:\APP_DIR\TLOG
TLOGNAME=TLOG
TUXDIR="C:\WLEdir"
MAXWSCLIENTS=10
SYS_GRP
LMID = SITE1
GRPNO = 1
ORA_GRP
LMID = SITE1
GRPNO = 2
/scott/tiger+SesTm=100+LogDir=.+MaxCur=5"
OPENINFO = "ORACLE_XA:Oracle_XA+Acc=P/scott/tiger
+SesTm=100+LogDir=.+MaxCur=5"
CLOSEINFO = ""
TMSNAME = "TMS_ORA"
DEFAULT:
RESTART = Y
MAXGEN = 5
TMSYSEVT
SRVGRP = SYS_GRP
SRVID = 1
SRVGRP = SYS_GRP
SRVID = 2
CLOPT = "-A -- -N -M"
SRVGRP = SYS_GRP
SRVID = 3
CLOPT = "-A -- -N"
SRVGRP = SYS_GRP
SRVID = 4
CLOPT = "-A -- -F"
SRVGRP = SYS_GRP
SRVID = 5
UNIVT_SERVER
SRVGRP = ORA_GRP
SRVID = 1
RESTART = N
SRVGRP = SYS_GRP
SRVID = 6
CLOPT = -A -- -n //MACHINENAME:2500
|
Copyright © 1999 BEA Systems, Inc. All rights reserved.
|