Application Continuity and Transaction Guard: Standing Guard Over Your Business Transactions

Have you ever bought flight tickets twice? Or have you ever waited for transaction commit in online-store, got an error and, later, found that money from your credit card was withdrawn? My friend has. OK, you find yourself in such unpleasant situation, buying goods or tickets one or two times. So, will you come back to this store or online tickets agency? I suspect the answer will be «No».  That is why it is necessary to understand how important to protect you business applications from such failures. We do not live in a perfect world, so power, communication, storage outage might happen from time to time and make impact on business and corporate applications. What is the result? Loosing clients? Damaging business? Fortunately Oracle can help you to protect your business and IT infrastructure from such kind of problems. 

Last summer, the latest releases of the flagship Oracle products, such as Oracle Database 12c and Oracle WebLogic Server 12c (12.1.2), has been released and now they support such vast important features such as Application Continuity and Transaction Guard. The main idea of these features – supporting at-most execution semantics in case of failures. The semantics assure that end-user transactions are executed on time and at-most-once.

So, what does it means? A common issue encountered in application environments is the loss of database connections. Loss of connections may be caused by transient problems such as temporary network outages, or failover that occurs across nodes in a RAC cluster. Even if the causes are transient, and connections can be re-established, loss of such connections causes exceptions, which must be handled by the application or surfaced back to end users, impacting application reliability. Oracle WebLogic Server 12c transparently leverages application continuity to address this issue with both GridLink and generic data sources. It provides continuous application services to end users, even when database connections are temporarily lost. Application Continuity automatically recreates lost connections, and replays database requests in process – including read and write operations. It is transparent to the application and the end user, providing highly reliable application services to the end user without any programming required by the developer. After a successful replay, the application can continue where that database session left off. Users are no longer left in doubt, not knowing what happened to their funds transfers, flight bookings, and so on; administrators no longer need to reboot mid-tier machines and recover from logon storms caused by failed sessions. With Application Continuity, the end user experience is improved by masking many outages, planned and unplanned, without requiring the application developer to attempt to recover the request.

Transaction Guard supplies a unique logical transaction identifier (LTXID) for each database transaction. This identifier can be used to query the Commit outcome of the transaction as well as to ensure that the transaction is applied only once. Transaction Guard is used by Application Continuity and automatically enabled by it and it can also be enabled independently. It prevents transactions that are replayed by Application Continuity from being applied more than once.

So, what you may need to configure environment? Let’s have a look!

  1. Enable Application Continuity on the Database service. The default service is not recommended and will not work. Below you can find sample script:

BEGIN

     DBMS_SERVICE.CREATE_SERVICE('AC','AC');

END;

/

DECLARE

  params dbms_service.svc_parameter_array;

BEGIN

  params('COMMIT_OUTCOME'):='true';

  params('RETENTION_TIMEOUT'):=604800;

  params('FAILOVER_TYPE'):='TRANSACTION';

  params('SESSION_STATE_CONSISTENCY'):='DYNAMIC';

  dbms_service.modify_service('AC',params);

END;

/

BEGIN

     DBMS_SERVICE.START_SERVICE('AC','ORCL');

END;

/

It is important to ensure that service is running before using your application (use START_SERVICE procedure from DBMS_SERVICE package).

  1. Create and configure simple WebLogic domain using Configuration Wizard or WLST. Note, that, it is not mandatory to have clustered environment for testing Application Continuity. But of course it is recommended to use clusterization and high availability both on mid-tier and DBMS side in production environment.
  2. In simplest case FOR NON PRODUCTION ENVIRONMENT you can use WebLogic Admin Server for testing Application Continuity feature. In this case it is necessary to add appropriate 12c drivers in the classpath. So, you should to export EXT_PRE_CLASSPATH environment variable in WebLogic start script. If we assume that Oracle Home for Database 12c is "/u01/app/oracle/product/12.1/database", use the following command to export variable and add it in startWeblogic.sh script (in Linux environment):

export EXT_PRE_CLASSPATH="/u01/app/oracle/product/12.1/database/rdbms/jlib/xdb.jar:/u01/app/oracle/product/12.1/database/jlib/orai18n-collation.jar:/u01/app/oracle/product/12.1/database/lib/xmlparserv2_sans_jaxp_services.jar:/u01/app/oracle/product/12.1/database/jlib/osdt_core.jar:/u01/app/oracle/product/12.1/database/jlib/osdt_cert.jar :/u01/app/oracle/product/12.1/database/jlib/oraclepki.jar:/u01/app/oracle/product/12.1/database/jlib/orai18n-mapping.jar:/u01/app/oracle/product/12.1/database/jlib/orai18n.jar:/u01/app/oracle/product/12.1/database/opmn/lib/ons.jar:/u01/app/oracle/product/12.1/database/ucp/lib/ucp.jar:/u01/app/oracle/product/12.1/database/jdbc/lib/ojdbc7.jar"

  1. Start WebLogic Admin Server.
  2. In WebLogic Admin Console (or using WLST) create generic datasource and use latest Replay Database Driver: Oracle Driver(Thin) for Application Continuity; Vesion 11.2.0.13 and later

  1. Use created datasource in your application.

Although Application Continuity may be enabled through properties files (datasource) and servers-side configuration, architects and application developers need to make some assessment in terms of exclusions, restrictions.

  1. Do not use the database service, that is, the default service corresponding to the DB_NAME or DB_UNIQUE_NAME. The use of the database service is not recommended for high availability, because this service cannot be enabled or disabled. Replay is not supported for applications developed using Oracle XA. For applications using JDBC, there is no support for oracle.sql deprecated concrete classes like BLOB, CLOB, BFILE, OPAQUE, ARRAY, STRUCT or ORADATA.
  2. Replay is disabled if the transaction executes the ALTER SYSTEM or ALTER DATABASE statement. Replay is not supported if you are using Active Data Guard with read/write database links to another database.
  3. Application Continuity is not supported for logically different databases - Oracle Logical Standby and Oracle Golden Gate.

So, tight integration between Oracle WebLogic Server 12c (12.1.2) and Oracle Database 12c enhances improved availability, better resource sharing, inherent scalability, ease of configuration and automated management facilities in a global cloud environment, which helps to use these both products as efficiently as possible. Oracle WebLogic Server is the only application server with this degree of integration to Oracle Database 12c.

You can find the following demo video regarding Application Continuity with WebLogic Server Integration

So, do not lose your time, protect your business as soon as possible!

Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

Oracle ECEMEA Partner Hubs Migration Center Team

We share our skills to maximize your revenue!
Our dedicated team of consultants can rapidly and successfully assist you to adopt and implement the latest of Oracle Technology in your solutions.

Stay Connected
partner.imc
@
beehiveonline.oracle-DOT-com
Google+

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
2
3
4
5
6
9
10
11
12
13
14
16
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today