Thursday Jan 08, 2015

Can you put a dollar value on saving lives?

Did you know that dirty water kills about 5000 children per day? This according to The Guardian, a Pulitzer prize winning British newspaper. That's almost 2 million children per year! And this is not counting people who fall sick from ingesting dirty water and the lack of productivity for parents and children who invest [waste?] a fair part of their day in search of clean water. Heartbreaking! This is why Safe Water Kenya was born and Don Arnold, a veteran of the plumbing industry, took it upon himself to leverage his expertize and correct this situation.


Although Don started with Kenya, Safe Water has plans to expand to Ghana, Uganda and greater part of Africa. Once Oracle and mFrontiers joined hands with Don, we encouraged him to expand to Asia, where, inspite of all the progress and countries being super powers and what not, a vast majority of the people still dont have access to clean water.

Come and listen to this heart warming story of how Safe Water leveraged a Mobile app built on enterprise software technology, like WebLogic and the Oracle Database, to provide clean water to Kenyans and to provide accountability to its donors with complete and immediate transparency.



Friday Oct 10, 2014

Announcing WebLogic on Oracle Database Appliance 12.1.3.0.0

Oracle WebLogic Server on Oracle Database Appliance 12.1.3 offers a complete solution for building and deploying enterprise Java EE applications in a fully integrated system of software, servers, storage, and networking that delivers highly available database and WebLogic services. The world's most popular database, Oracle Database and the industry's best application server, WebLogic Server have been combined in this industry-unique appliance to provide high availability and the simplicity of One-Button deployment. And to top it all off, it reduces IT cost with a unique capacity-on-demand software licensing model.

Here you can download the new version of WebLogic on ODA 12.1.3 which offers WebLogic templates for 11g  (10.3.6), 12c (12.1.2 and 12.1.3).

http://www.oracle.com/technetwork/middleware/weblogic-oda/downloads/index.html

The following highlighted new features are included in this release:

  • Oracle Database 12c support on ODA integrated with WebLogic Server.
  • WebLogic on ODA provisioning tool now offers not only multi domain and multi cluster options in the wizard-driven templates, but also the single WebLogic instance provisioning.
  • Provides Coherence provisioning in the wizard-driven templates.
  • Much faster provisioning with new ‘snap’ feature
  • New licensing options include a 'pool' of WebLogic licenses with min/max range, that can be allocated to WebLogic, Oracle Traffic Director and other Oracle Cloud Application Foundation products.

Monday Aug 04, 2014

Setting V$SESSION for a WLS Datasource

Every Oracle database connection runs in the context of a database process called a session.  There is a v$session view that contains a lot of information about the database sessions that are active.. By default when you use the Oracle Thin Driver, the value v$session.program is set to "JDBC Thin Client".  That separates out the Java applications from sqlplus and the scores of database background programs but doesn't provide much additional information since all of the Java connections look the same.  It's easy to set this and some other values on v$session using connection properties on the Oracle Thin driver.  The following connection properties are supported:  v$session.osuser, v$session.process, v$session.machine, v$session.terminal, and v$session.program.  Setting these will set the corresponding value on the session on the database side.  These values are then available from the v$session view.

The simple approach is to hard-code a value into a normal connection Property.  That's fine if you want to associate a fixed value with a data source.  It's more interesting if you dynamically set the value at runtime. For example, if there are multiple servers running within a domain and the information needs to be server specific, a normal cluster deployment with one fixed value is not useful, and the option of deploying the DataSource to every server individually and then hand-editing each one's descriptor with unique values for these properties is not manageable. You can easily handle this using a System Property.  The value that is specified is taken to be a Java system property that you set on the command line of the application server.  It is retrieved using System.getProperty() and set as the value of the connection property.    There's a new Encrypted Property in WLS 12.1.3; I'll write another article about that.

If you use bin/startWebLogic.sh to start the server, it will put -Dweblogic.Name=${SERVER_NAME}on the command line.  If you set the v$session.program System Property connection property to "weblogic.Name", your session program value will match the WLS server that is making the connection. 

You can set connection properties by editing the data source configuration on the "Connection Pool" tab in the WebLogic administration console.  Properties are set in the Properties and System Properties text boxes.  Let's say that I set four of the values to test values and one to a system property, generating the descriptor fragment as follows.

<property>
  <name>v$session.osuser</name>
  <value>test1</value>
</property>
<property>
  <name>v$session.process</name>
  <value>test2</value>
</property>
<property>
  <name>v$session.machine</name>
  <value>test3</value>
</property>
<property>
  <name>v$session.terminal</name>
  <value>test4</value>
</property>
<property>
  <name>v$session.program</name>
  <sys-prop-value>weblogic.Name</sys-prop-value>
</property>

Alternatively, you could set these values using on-line or off-line WLST.

Here's a fragment of an off-line WLST script.

cd('/JDBCSystemResource/myds/JdbcResource/myds') cd('JDBCDriverParams/NO_NAME_0') cd('Properties/NO_NAME_0') create('v$session.program','Property') cd('Property') cd('v$session.program') set('SysPropValue', 'weblogic.Name')

If $SERVER_NAME is myserver and I then go to run a query, here is the resulting output.

SQL> select program, osuser, process, machine, terminal 
  from v$session where program = 'myserver';
myserver test1 test2 test3 test4

If the server names aren't obvious enough, you could set the program to "WebLogic Server $SERVER_NAME".  You could set -Djdbc.process=<PID> to tie connections to a specific WLS server process. You might want to add the WLS data source name to the program value.  You could set osuser to the Java value "user.name".

 Using system properties can make this a powerful feature for tracking information about the source of the connections, especially for large configurations.


Monday Jun 16, 2014

Detailed Analysis of a Stuck Weblogic Execute Thread Running JDBC Code

The following thread was extracted from a thread dump taken on a JVM instance running WebLogic Server.

In this post I will deconstruct this thread and describe the data it contains and the potential issues it may illuminate.

[STUCK] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)' id=73 idx=0x128 nid=13410 prio=1 alive, in native, daemon 

 java.net.SocketInputStream.socketRead0(Native Method)

java.net.SocketInputStream.read(SocketInputStream.java:129)

oracle.net.ns.Packet.receive(Unknown Source)

oracle.net.ns.DataPacket.receive(Unknown Source)

oracle.net.ns.NetInputStream.getNextPacket(Unknown Source)

oracle.net.ns.NetInputStream.read(Unknown Source)

oracle.jdbc.driver.T4CMAREngine.unmarshalUB1(T4CMAREngine.java:1099)

oracle.jdbc.driver.T4CMAREngine.unmarshalSB1(T4CMAREngine.java:1070)

oracle.jdbc.driver.T4CTTIoauthenticate.receiveOauth(T4CTTIoauthenticate.java:751)

oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:362)

oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:420)

oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:165)

oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:35)

oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:801)

java.sql.DriverManager.getConnection(DriverManager.java:140)

com.foo.abc.util.ConnectionPool.createConnection(Unknown Source)

This thread is considered Stuck by WebLogic because it's been running for over the time defined in MaxStuckThreadTime (600 seconds by default). Weblogic Server waits for this time to be reached before marking a thread as stuck if the thread is still working after this time.  If you deem that 600 seconds is too long before a running thread is considered stuck then you can change the value of the this parameter using the WebLogic Console (as shown below), or use setMaxStuckThreadTime from the ServerFailureTriggerMBean interface.

An error including BEA-000337 will be logged in the server log file when the thread changes its status to stuck but the server won't take further action on this thread.  However, you might want to investigate why this thread is taking such a long time to process the work assigned to it.

Lets now look at the thread itself.  From its header, you can spot the thread identifier (2 in this example) and the queue where it originated.  The term Self-tuning indicates that the associated thread pool consistently checks the overall throughput to determine if the thread count should change.

id (or tid) is the thread identifier, a unique process-wide number that identifies this thread within the JVM process.  This id is unique but can be reused by another thread once this thread is terminated. 

nid is the OS-level native thread identifier.  It can be used effectively to correlate with high CPU usage threads identified at the OS level (e.g. with Linux watch command).  See Unexpected High CPU Usage with WebLogic Server (WLS) Support Pattern (Doc ID 779349.1) for detailed steps.

idx is the thread index in the threads array.

prio refers to the thread priority, a number inherited from the thread that created it.  You can learn more about thread priorities at Class Thread but basically threads with higher priority are executed in preference to threads with lower priority.

alive refers to the fact that this thread has not ended yet and is still active.  

in native means that the thread uses the operating system's native ability to manage multi-threaded processes.  

daemon indicates that this thread can't prevent the JVM from exiting.

The thread header is accompanied with a full java stack which lists each method and class invoked since the first assignement to the thread up to its most recent action. This thread consists of obtaining a connection to an Oracle database using a Type 4 JDBC driver and then issuing a call but getting no response from the back end database server.  The database failed to respond, and the thread has probably been in the same waiting mode (unchanged and not progressing java stack) for a long time since it's now considered stuck; the most recent invocation being java.net.SocketInputStream.socketRead0.

At this point the back end database needs to be checked to understand why it's not responding to the java thread request.  A starting point could be to query v$session to find potential blocking sessions at the database level.

Blocking sessions occur when one session holds an exclusive lock on an object and doesn't release it.

Needless to say, the communication with the database needs to be confirmed as healthy with none to very limited latency.  Firewall issues should be ruled out as well.  Firewalls could time out idle sockets used by JDBC connections to the database and lead to not closing the socket the JDBC driver is using.

Wednesday Apr 30, 2014

NEC Touts Oracle WebLogic Active GridLink for RAC Benefits

Japanese multinational, NEC corporation, plans on offering the unique Active GridLink for RAC, providing intelligent integration between Oracle WebLogic Server and Oracle Real Application Clusters (RAC), to customers for its higher performance, availability, and simplified operations. Check out Naoto Kashiwagi, Assistant Manager, NEC discuss Active GridLink benefits in great detail.

Friday Feb 21, 2014

Part II: WebLogic-Database Integration Podcast Series

In this part two of a three-part series podcast, Oracle's WebLogic Database integration expert Monica Riccelli highlights capabilities from the brand new 12c integration such as application continuity and DRCP. Monica and I discuss the capabilities in detail along with customer use cases and benefits. Tune into the podcast.

Wednesday Jan 15, 2014

Announcing WebLogic on Oracle Database Appliance 2.7

Oracle WebLogic Server on Oracle Database Appliance 2.7 offers a complete solution for building and deploying enterprise Java EE applications in a fully integrated system of software, servers, storage, and networking that delivers highly available database and WebLogic services. The world's most popular database, Oracle Database and the industry's best application server, WebLogic Server have been combined in this industry-unique appliance to provide high availability and the simplicity of One-Button deployment. And to top it all off, it reduces IT cost with a unique capacity-on-demand software licensing model.

Here you can download the new version of WebLogic on ODA 2.7 which offers WebLogic template for 11g  (10.3.6), 12c (12.1.1 and 12.1.2).

http://www.oracle.com/technetwork/middleware/weblogic-oda/downloads/index.html


Thursday Oct 17, 2013

So what is Active GridLink for RAC?

I had referred to Active GridLink for RAC in my blog yesterday and since then got several questions on this topic. So I decided to re-visit Active GridLink. With the release of version 11g, Oracle WebLogic Server started to provide strong support for the Real Application Clusters (RAC) features in Oracle Database 11g, minimizing database access time while allowing transparent access to rich pooling management functions that maximizes both connection performance and availability. WebLogic is the only application server in the marketplace which has been fully integrated and certified with Oracle Database RAC 11g without losing any rich functionality. Active GridLink provides Fast Connection Failover (FCF), Runtime Connection Load-Balancing (RCLB), and RAC instance graceful shutdown. With the key foundation for providing deeper integration with Oracle RAC, this single data source implementation in Oracle WebLogic Server supports the full and unrestricted use of database services as the connection target for a data source.


For more details and to understand how our customer NEC leverages this capability, read the whitepapers on this topic.

Get in depth ‘how-to’ details from this youtube video from our resident expert, Frances Zhao.

Wednesday Oct 16, 2013

Oracle WebLogic Server and Oracle Database: A Robust Infrastructure for your Applications

It has been said that a chain is as strong as its weakest link. Well, this is also true for your application infrastructure. Not only are the various components that constitute your infrastructure, like database and application server critical, the integration between these things [whether coming out of the box from your vendor or done in-house] is paramount. Imagine your database being down and your application server not knowing about it and as a result your application waiting indefinitely for a database response – not a great situation if high availability is critical to your application. Or one of your database nodes is very busy, but your application server doesn’t have the intelligence to decipher that – it keeps pinging the busy node when it can in fact get a response from another idle node much faster. This is what Oracle WebLogic and Database integration provides: Intelligent integration out of the box. Tight integration between Oracle WebLogic and Database makes your infrastructure robust enough that not only does each of your infrastructure component provide you with improved RASP [reliability availability, scalability, and performance] but these components work together to offer improved performance & availability, better resource sharing, inherent scalability, ease of configuration and automated management for your entire infrastructure. Oracle WebLogic Server is the only application server with this degree of integration to Oracle Database.

With Oracle WebLogic Server 11g, we introduced Active GridLink for Real Application Clusters (RAC). In conjunction with Oracle Database, this powerful software technology simplifies management, increases availability, and ensures fast connection failover with runtime connection, load balancing and affinity capabilities. With the release of Oracle Database 12c this summer, even tighter integration between Oracle WebLogic Server 12c (12.1.2) and Oracle Database 12c has been achieved and this further optimizes the integration for a global cloud environment.


Read about these capabilities in detail in the Oracle WebLogic-Database Integration Whitepaper. Get in depth ‘how-to’ details from this YouTube video on the topic from our resident expert, Monica Roccelli.

Friday Sep 20, 2013

Another not-to-miss OpenWorld Session: WebLogic on Oracle Database Appliance

Oracle WebLogic Server on Oracle Database Appliance offers a complete solution for building and deploying enterprise Java EE applications in a fully integrated system of software, servers, storage, and networking that delivers highly available database and WebLogic services.
In this session, we will discuss how WebLogic is deployed on Database Appliance virtual environment and what the benefits of deploying to this platform are.

Session Id: CON8980

Time: Monday, Sept 23rd 2013, 12:15 p.m. - 1:15 p.m.

Location: Marriott Marquis, Room: Golden Gate A

Speakers: Simon Haslam (Veriton), Frances Zhao-Perez (Oracle)

Read Simon's blog for more information on this session.

More on the topic from OTN.


 

Thursday Sep 05, 2013

Part 3 - 12c Database and WLS - Multi Tenant Database (CDB/PDB)

I introduced WLS support for 12c database at https://blogs.oracle.com/WebLogicServer/entry/part_1_12c_database_and and the Application Continuity feature at https://blogs.oracle.com/WebLogicServer/entry/part_2_12c_database_and  . 

One of the biggest new features in the 12c database is officially called the Oracle Multitenant option. I'm going to point out what I think are some of the highlights here and eventually get down into some WLS sample code.  See http://docs.oracle.com/cd/E16655_01/server.121/e17636/part_cdb.htm#BGBIDDFD for the Oracle Database Administration documentation for this feature.  Technical folks, administrators and programmers, will call this feature "CDB/PDB" after the Container Database and Pluggable Databases that are used to implement it.  As the names imply, you have a CDB to contain a collection of PDB's.  If you are an administrator, you can appreciate the ability to create, manage, monitor, backup, patch, tune, etc. one entity instead of a bunch of them.  As a programmer, its great that you can connect to your PDB and it looks and behaves just like a non-PDB.  All that you need to know is the host, port, and service name just like the non-PDB.  Of course, the service name needs to be unique in your environment so that you get to the right PDB in the right CDB.

As you might expect, there needs to be a container at the top to hold all of the PDB's - it's called the CDB$ROOT.  There also needs to be some users in charge of the PDB's.  These users are called "common users" and the names must begin with "C##".  A common user is created in the root (it fails within a PDB) and exist in all PDB's. "Local users" are created within individual PDB's and behave like users in non-PDB's.  When you are doing administration from tools like sqlplus or sqldeveloper, you connect to the database in the root and can switch to a PDB by using something like  "alter session set container = PDB1" and then "alter session set container = CDB$ROOT" to get back to the root.  There are new views to keep track of the CDB/PDB information - use "select pdb from cdb_services where pdb is not null" to see what PDB's exist.  Some operations can only be done at the root level.  For example, Database Resident Connection Pooling (DRCP), another new 12c feature, can only be started at the root.  A PDB is managed pretty much like a non-PDB with startup and shutdown.  Each PDB has an administrative database service that you can't configure (Enterprise Manager needs something consistent to manage the PDB) and you can create additional database services with your own choice of attributes. You can use  the dba_services table within a PDB to see just the services for that PDB.

So how do you use this?  The easy way to use this is for improving density and scalability on the data tier.  You can move multiple standalone databases into a single container database with individual PDB's corresponding to each standalone database.  On the WebLogic Server side, you can still have a data source defined for each of these PDB's, just as you have today. 

Feeling more ambitious?  You can share a single data source across multiple PDB's.  To do that, you need to get a connection and switch to the PDB that you want to work on by executing the SQL statement "ALTER SESSION SET CONTAINER = pdbname".  You might be wondering if any state is leaked from one PDB to another by doing this.  Under the covers, the Oracle database server tells the Oracle driver that the PDB has been switched so driver connection state can be cleaned up.  Then the driver tells the WLS data source that the PDB has been switched so that the WLS connection state can be cleaned up. Although general use of a PDB is transparent to WLS so that  it can be used with versions starting with WLS release 10.3.6, PDB SET CONTAINER isn't supported until WLS release 12.1.2.

Switching PDB's is not a cheap operation so you should minimize doing this.  To minimize the overhead, you really want to keep track of what PDB is associated with each connection.  WLS data source has a mechanism for associating labels with connections that's ideal for this purpose.  See http://docs.oracle.com/middleware/1212/wls/JDBCA/ds_labeling.htm#BCGFADIH  for the connection labeling documentation.

Take a look at the sample code at this source code link (the .txt file is actually a .java file).  It's written up as a servlet (don't get caught up in those details). It assumes that there is a 12c container database with PDB1 and PDB2 that has been configured as a generic data source with a JNDI name "ds0".  When it first gets the data source, a labeling callback is created and registered (we only want to do this once).    The program gets connections on each PDB.  The first time it gets a connection on a PDB, it needs to do a switch; the next time, it can reuse the same connection.   The labeling getConnection API is used; it takes a Properties object and the label name is "TENANT".  Looking at the callback, if the label properties match then 0 is returned, otherwise a non-zero value is returned (some debugging information is printed so it's possible to watch the matching process).  The key work is in the configure method, which is called when the tenant label doesn't match.  In that case, the SET CONTAINER is done using the tenant label value and the label properties are reset.

Climbing back out of the code, the Oracle Multitenant option can be a big win on the database server side immediately with no change on the WLS side except maybe for the URL in the JDBC descriptor.  Longer term, I believe applications will want higher density on the mid-tier and start to collapse the number of data sources. Along the same lines of improving density but not for multiple tenants, you can also move your SALES and CRM databases into PDB's within a container, and merge the two data sources into a single data source using the methods described above.  It will be interesting to see how customers leverage the power of this new feature.

Tuesday Aug 13, 2013

Announcing WebLogic Server on Oracle Database Appliance 2.6

Would you like to learn a solution that saves time and money by simplifying deployment, maintenance, and support of high availability Oracle Database and WebLogic Server?

We are announcing exciting news of the availability of “Oracle WebLogic Server on Oracle Database Appliance 2.6”!

www.oracle.com/technetwork/middleware/weblogic-oda/overview/index.html

Oracle WebLogic Server on Oracle Database Appliance 2.6 offers a complete solution for building and deploying enterprise Java EE applications in a fully integrated system of software, servers, storage, and networking that delivers highly available database and WebLogic services. Built with world’s most popular database, Oracle Database and the industry’s best application server, Oracle WebLogic Server, and with its One-Button deployment capability, it delivers the combined high availability and simplicity. It reduces IT cost with the unique capacity-on-demand software licensing model.

For fully redundant system, storage, Oracle Database Appliance Manager Information, please check out the Oracle Database Appliance data sheet.

Oracle WebLogic Server on Oracle Database Appliance 2.6 provides:

  • Highly available WebLogic Server with two, four or eight node cluster options that provide the foundation for customers to build and deploy enterprise Java EE applications with support for new features in WebLogic 11g (10.3.6) and 12c (12.1.1).
  • Simple, reliable, affordable platform for deploying end-to-end solutions leveraging not only Oracle Database Real Application Clusters, but also WebLogic and the software load balancer for customers’ Java EE and Database investments.

The following new features are included in this new release:

  • WebLogic on ODA 2.6 is fully certified with Oracle Database Appliance X3-2 hardware
  • Oracle Traffic Director becomes optional during provisioning process
  • User input the licensed core count, provisioning then it creates pools on the compute nodes and configure Traffic Director and WebLogic Server VMs to use the pools.
  • Oracle Traffic Director 11.1.1.7 template for the load balancer tier

Please check out the white paper, howto, FAQ, etc for more information.

www.oracle.com/technetwork/middleware/weblogic-oda/overview/index.html

Friday Aug 09, 2013

Oracle and NEC Joint White Paper: WebLogic Server Active GridLink for Oracle RAC Testing Scenarios and Results

Oracle and NEC have been jointly invested on verifying and testing the Active GridLink for RAC solution implemented within Oracle WebLogic Server which gives the rich functionality for  Oracle Database Real Application Clusters integration.
The combination of Oracle WebLogic Server Data Source and Connection Pooling solutions and Oracle RAC provides a high-end mission-critical environment offering performance, high scalability and availability features. Load-balancing and Affinity capabilities offersignificant performance improvement for online transaction processing scenarios, as well as improving throughput and total response time. Failover solution gives end-to-end rapid failure detection supporting graceful shutdown for planned and unplanned Oracle RAC node outages.
In this paper, we start with a brief introduction to Oracle RAC and an overview of the Oracle RAC features supported in Oracle WebLogic Server 11g and 12c. We then focus on details of the effort that have been jointly done with Oracle and NEC with all the detailed testing scenarios and testing results, along with the analysis. The background and overview of NEC’s test of Active GridLink for RAC will be covered in details. The technical details about Runtime Connection Load Balancing, Web Session Affinity, Fast Connection Failover, and how to remove and add the additional RAC node with zero-downtime will be discussed with different use cases.


Download the white paper! And please share your comments
http://www.oracle.com/technetwork/middleware/weblogic/overview/activegridlinkwhitepaperoraclenec-1987937.pdf


Enjoy!

Monday Jul 29, 2013

New Whitepaper – Cloud Performance, Elasticity and Multitenancy with Oracle WebLogic Server 12c and Oracle Database 12c

One of the exciting focus areas of Oracle WebLogic 12c release 12.1.2 is the deep integration with the recently available Oracle Database 12c.

To hear live about these key integration features, please join our launch event on July 31st

One of the advantages of having the world’s most popular Database and the #1 Application Server under one roof, is the simple rule of 1+1=3, and what do I mean by that?

With our Engineering teams on the Database and Middleware side working hand in hand, Oracle WebLogic Server 11g introduced Active GridLink for Real Application Clusters (RAC). In conjunction with Oracle Database, this powerful software technology simplifies management, increases availability, and ensures fast connection failover, with runtime connection, load balancing and affinity capabilities. Deltek is one of the early adopters of these capabilities. Watch their video

With the release of WebLogic Server 12c (12.1.2), tight integration between Oracle WebLogic Server 12c (12.1.2) and Oracle Database 12c enhances these capabilities with improved availability, better resource sharing, inherent scalability, ease of configuration and automated management facilities in a global cloud environment.


It’s worth noting that Oracle WebLogic Server is the only application server with this degree of integration with Oracle Database 12c.

This white paper, authored by Monica Riccelli and Frances Zhao from the CAF Product Management team, explains how these unique database, clustering, and application server technologies work together to enable higher availability, scalability and performance for your business. It starts by introducing Oracle Active GridLink for RAC with attention to ease of configuration, manageability, and performance. Then describes the impact of Oracle WebLogic server on several leading features of Oracle Database12c such as Multitenant Databases (Pluggable Database), Database Resident Connection Pool, Application Continuity, and Global Data Services.

Please download the whitepaper and let us know your feedback!

You can read more on this topic in these blogs by Steve Felts:

Part 1 - 12c Database and WLS – Overview

Part 2 - 12c Database and WLS - Application continuity


Monday Jul 22, 2013

Part 2 - 12c Database and WLS - Application continuity

I introduced WLS support for 12c database in this blog link and described one of the prerequisites for Application Continuity (AC) at this blog link.

When an error occurs on a connection, it would be nice to be able to keep processing on another connection - that's what AC does.  When on a single node database, getting another connection means that the database and network are still available, e.g., maybe just a network glitch.  However, in the case of a Real Application Cluster (RAC), chances are good that even if you lost a connection on one instance you can get a connection on another instance for the same database.  For this feature to work correctly, it's necessary to ensure that all of the work that you did on the connection before the error is replayed on the new connection - that's why AC is also called replay. To replay the operations, it's necessary to keep a list of the operations that have been done on the connection so they can be done again.  Of course, when you replay the operations, data might have changed since the last time so it's necessary to keep track of the results to make sure that they match.  So AC may fail if replaying the operations fail.

You can read the WLS documentation, an AC white paper, and the Database documentation to get the details. This article gives an overview of this feature (and a few tidbits that the documentation doesn't cover).

To use this feature, you need to use both the 12c driver and a 12c database.  Note that if you use an 11.2.0.3 driver and/or database, it might appear to work but replay will only happen for read-only transactions (the 11g mode is not supported but we don't have a mechanism to prevent this).

You need to configure a database service to run with AC.  To do that, you need to set the new 12c service attributes FAILOVER_TYPE=TRANSACTION and COMMIT_OUTCOME=true on the server side.

There's not much to turning on AC in WLS - you just use the replay driver "oracle.jdbc.replay.OracleDataSourceImpl" instead of "oracle.jdbc.OracleDriver"  when configuring the data source.  There's no programming in the application needed to use it.  Internal to WLS, when you get a connection we call the API to start collecting the operations and when you close a connection we call the API to clear the operation history.

WLS introduced a labeling callback for applications that use the connection labeling feature.  If this callback is registered, it will be called when a new connection is being initialized before replay.  Even if you aren't using labeling, you might still want to be called and there is a new connection initialization callback that is for replay (labeling callback trumps initialization callback if both exist).

It sounds easy and perfect - what's the catch?   I've already mentioned that you need to get rid of references to concrete classes and use the new Oracle interfaces.  For some applications that might be some significant work.  I've mentioned that if replaying the operations fails or is inconsistent, AC fails.  There are a few other operations that turn off AC - see the documentation for details. One of the big ones is that you can't use replay with XA transactions (at least for now).   Selecting from V$instance or sys_context  or other test traces for test instrumentation needs to be in callouts as the values change when replayed.  If you use sysdate or systimestamp, you need to grant keep date time to your user.

We are also tracking two defects - AC doesn't work with Oracle proxy authentication and it doesn't work with the new DRCP feature. 

There's another more complex topic to consider (not currently in the current WLS documentation).  By default, when a local transaction is completed on the connection, replay ends.  You can keep working on the connection but failure from that point on will return an error to the application. This default is based on the service attribute SESSION_STATE_CONSISTENCY with a value of DYNAMIC.  You can set the value to STATIC if your application does not modify non-transactional session state (NTSS) in the transaction.  I'm not sure how many applications fall into this trap but the safe thing is to default to dynamic.  I'll include such a code fragment below.  A related common problem that people run into is forgetting to disable autocommit, which defaults to true, and the first (implicit) commit turns off replay if SESSION_STATE_CONSISTENCY is set to DYNAMIC.

It's important to know how to turn on debugging so that if a particular sequence doesn't replay, you can understand why.  You simply need to run with the debug driver (ojdbc6_g.jar or ojdbc7_g.jar) and run with -Dweblogic.debug.DebugJDBCReplay (or turn this debug category on in the configuration).

AC won't replay everything and you still need to have some application logic to deal with the failures or return them to the end user.  Also, there's some overhead in time and memory to keep the replay data.  Still, it seems like a great feature for a lot of applications where you don't need to change anything but the driver name and you can avoid showing an error to the end user or simplify some recovery logic.

P.S. Confused about NTSS? So was I.  Examples of non-transactional session state that can change at run-time are ALTER SESSION, PL/SQL global variables, SYS_CONTEXT, and temporary table contents.  Here's an example of a PL/SQL global variable.  Imagine a package with the following body:

 current_order number := null;
 current_line number;
 procedure new_order (customer_id number) is
  current_order := order_seq.nextval;
  insert into orders values (current_order, customer_id);
  current_line := 0;
 end new_order;
 procedure new_line (product_id number, count number) is
  current_line := current_line + 1;
  insert into order_lines values (current_order, current_line,product_id, count);
 end new_line;
end order;

and a psuedo-code sequence in WLS like this:
getConnection()
exec "begin order.new_order(:my_customer_id); end;"
commit;
exec "begin order.new_line(:my_product_id, :my_count); end;"
<DB server failure and failover>
commit;

In this scenario, we won't replay the first transaction, because it's already committed and we'd end up with two orders in the database. But if we don't replay it, we lose the order_id, so the new_line call won't work. So we have to disable replay after the commit.  If you can guarantee that no such scenario exists, you can mark the service session-state as static.



About

The official blog for Oracle WebLogic Server fans and followers!

Stay Connected

Search

Archives
« July 2015
SunMonTueWedThuFriSat
   
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
       
Today