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/ 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.


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 "".

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

Friday Aug 01, 2014

Using 3rd party JDBC Jar Files

If you look at the documentation for adding a 3rd party JDBC jar file, it recommends adding it to the system classpath by updating  See  However, there more options with some advantages and disadvantages.  To use some of these options, you need to know something about application archive files.

The general precedence of jar files in the classpath is the following:

system classpath >> DOMAIN_HOME/lib >> APP-INF/lib >> WEB-INF/lib

The highest priority is given to jar files on the system classpath.  The advantage of using the system classpath is that it works for all environment including standalone applications. 

The rest of the options only work for applications deployed in the application server.  That includes the WLS administration console and WLST but not an application like 'java utils.Schema'.  These approaches work on WLS 10.3.6 and later.

The simplest way to add a jar file when you don't need it accessed in a standalone application is to drop it in DOMAIN_HOME/lib.  This is an easy way to access a driver for a data source in the application server. It won't work for jar files that are shipped with WLS and already part of the system classpath because the system classpath takes precedence.  That's why this article focuses on "3rd party" jar files.  More information and recommendations about using DOMAIN_HOME/lib can be found at .

APP-INF/lib will only work in an EAR file and applies to all applications in the EAR file.  APP-INF is located at the root directory in the EAR file at the same level as META-INF.  This approach and the next have the advantage of packaging the driver with the application archive.  However, it's not efficient if the driver is needed by more than one archive and you probably should use DOMAIN_HOME/lib.

WEB-INF/lib only works in a WAR file and must be located at the root directory in the WAR file.  It only applies to the corresponding web application.  By using a WEB-INF/weblogic.xml file that has "<prefer-web-inf-classes>true</prefer-web-inf-classes>", the jar files in WEB-INF/lib take precedence over others (that is, the default precedence defined above is overridden).  This is useful if you want different versions of the driver for different applications in various WAR files.   Note that starting in WLS 12.1.1 with Java EE 6 support, it's possible to have a standalone WAR file that is not embedded in an EAR file.

Here's an indented list that attempts to capture the hierarchy of the files and directories described above in EAR and WAR files.

Application (ear)

  • Web module (war)
    • WEB-INF/lib
    • WEB-INF/web.xml
    • WEB-INF/weblogic.xml
  • EJB module
  • APP-INF/lib

There is sample code for a WAR file at this link.  The data source definition can appear either as a descriptor in web.xml or as an annotation in the java file.  weblogic.xml can be used to set prefer-web-inf-classes appropriately.  The @Resource annotation is used to reference the data source in the application code.  This program prints the version of the driver.  You can play with two versions of the Derby driver to see how the precedence works.

Note:  You can't have two versions of the same jar in both domain/lib or the system classpath and  WEB-INF/lib or APP-INF/lib with prefer-web-inf-classes or prefer-application-packages set.  That is, either you use domain/lib or system classpath to get it into all applications in the domain or you use it embedded in the application but not both.  If you don't follow this restriction, it's possible (depending on the jar, the version changes, and the order in which the jars are referenced) that a ClassCastException will occur in the application.

The choice of where you locate the JDBC jar file depends on your application.  For standalone application access, use the system classpath.  For simple access in all or most applications, use DOMAIN_HOME/lib.  For access across an EAR file, use APP-INF/lib.  For access within a single WAR file, use WEB-INF/lib.

Sunday Jul 27, 2014

Data Source Connection Labeling

The connection labeling feature was added in WLS release 10.3.6. This feature has the potential to reduce the overhead when there is work to initialize a connection for application use. Labeling connections allows an application to attach arbitrary name/value pairs to a connection. The application can request a connection with the desired label from the connection pool. By associating labels with connection states, an application can retrieve an already initialized connection from the pool and avoid the time and cost of re-initialization. This feature is described in good detail including an example at .

Connection Labeling is enhanced in release WLS 12.1.3.  For some applications, it's possible that making a connection conform if it doesn't match can be so expensive that a new connection should be created instead of using an existing connection but only up to some threshold.  The enhancement introduces the notion of a "high-cost connection".  There are two new connection properties that can be configured on the data source descriptor.

New Connection Property Default Value Usage
ConnectionLabelingHighCost Integer.MAX_VALUE If connection label cost >= this value, considered high-cost connection.
HighCostConnectionReuseThreshold 0 When > 0, number of connections in pool when high-cost connections are re-used

This following list spells out the rules in more detail when getting a connection using labeling properties. All available connections are evaluated to get their cost using the registered labeling callback.

  • If the cost for a connection is greater than or equal to ConnectionLabelingHighCost, it is a High-Cost Connection.
  • When the lowest-cost available connection is a High-Cost Connection, test current pool size against Reuse High-Cost Connection Threshold and against minimum pool size.
  • If the current connection count is less than the minimum or threshold values, return a new connection instead of the high-cost connection.
  • Otherwise (current connection count is greater than or equal to the threshold), return the lowest-cost High-Cost Connection.
  • Labeled connections with cost value Integer.MAX_VALUE will never be reused (same as prior release).
  • The maximum pool size constraint still holds (i.e. if threshold > maximum pool size, maximum pool size governs).
  • The minimum pool size constraint holds (i.e. if threshold < minimum pool size, minimum pool size governs).
  • Leaving the threshold unset results in same behavior as threshold = minimum (i.e., if current >= minimum, return the lowest-cost connection, which in this case is a High-Cost Connection).
  • When there are no available connections, use the standard behavior.  That is, return a new connection subject to maximum pool size.  If the current size is greater than or equal to the maximum pool size, wait for a connection to be available, subject to the timeout, etc.

Here is a simplified sample configuration file.

    <test-table-name>SQL ISVALID</test-table-name>

The connection labeling properties can be configured in the properties text box in the administration console or can be created using WLST. In this example, a high cost connection has a cost greater than or equal to 5.  The threshold is 20 connections, which is greater than the initial capacity of 0 and less than the maximum capacity of 25 so there is no interference.  Note that in the configuration above, the connection labeling callback is registered in the configuration file; alternatively it can be registered in the application code.

The following table describes the behavior when ConnectionLabelingHighCost=5 and HighCostConnectionReuseThreshold=20 for various values of connection labeling cost. 

Total Connections in Pool Minimum cost connection available Action
0-19 None available Create new connection
0-19 0-4 Use existing connection
0-19 >=5 Create new connection; don't use high-cost connection
>=20 None available Create new connection
>=20 0-4 Use existing connection
>=20 5 Use existing high-cost connection

There is a sample program for handling PDB switching in a Multi-Tenant Database environment using connection labeling at . The sample uses the label to keep track of the PDB associated with each connection.  The sample can't take advantage of this new feature because it always returns Integer.MAX_VALUE for a mismatch so the connections will never be reused. Instead, we could return some value that is equal to the configured ConnectionLabelingHighCost. Just by changing Integer.MAX_VALUE to 5 in the callback, we will create new connections up to 19 connections and then start reusing connections.

The connection labeling feature  processing isn't free.  The connection cost is computed for all available connections every time a connection is reserved.  But in the case that connection initialization is expensive, it can perform much better.

Thursday Jul 24, 2014

Improved High Availability with Whole Server Migration on Dynamic Clusters

If you remember, we added Dynamic Clusters in WebLogic Server 12.1.2. Dynamic Clusters make it really easy to configure a cluster and to scale up that cluster. They are a cloud-enabling technology that provides elasticity for your applications. We’re always looking to improve on a good thing, so in WebLogic Server 12.1.3, we enabled Whole Server Migration with Dynamic Clusters. Whole Server Migration enhances the availability of clusters by enabling a failing/failed managed server to be restarted automatically on a different machine. This is especially important for recovery of persistent JMS messages and distributed transactions.

I just posted a video on YouTube with more details and a short demo. Take a look:

If you want to learn more:

Wednesday Jul 23, 2014

Developing Java EE applications with Maven and WebLogic 12c

Like many other developers, Zemian Deng is finding the new Maven support in WebLogic 12c quite slick.

Check out his post at to learn a few useful tips.

Thursday Jul 17, 2014

Exciting New JTA 12.1.3 Feature “XA Transaction without Transaction Logs”

One of the most exciting new features in WebLogic Server 12.1.3 is a JTA new feature
“XA Transaction without Transaction Logs.” This feature does not only provide performance optimization when applications use XA transactions, but also has great advantages for Disaster Recovery scenarios.

XA transactions provide a standards-based mechanism to preserve data integrity for mission-critical applications. Traditionally XA transaction recovery requires the transaction manager to persist transaction records to stable storage (TLog) after all of the transactions resources have been prepared, and purging them after all of the transactions resources have been completed. However, recording pending transactions for recovery purposes requires additional I/O which affects performance. In cases of disaster recovery transaction logs need to be replicated to make sure that global transactions can be recovered.

XA Transaction without Transaction Logs,” uses a determiner resource which can be either a DataSource or a WebLogic JMS resource to determine the recover outcome of pending transactions. When using a determiner resource, WebLogic Server will no longer write and purge transaction checkpoints to TLogs. XA Transaction without Transaction Logs,” takes advantage of the two-phase-commit protocol, as well as prepare and commit ordering of resources participating in the global transaction to determine if pending transactions need to be recovered with a commit or a rollback.

The advantages of this feature are:

· Up to three times performance throughput improvement

· Prepare and Commit ordering

· I/O latency removed by not writing to TLOG (default file store)

· Resource and/or batch blocking removed (JDBC Tlog)

· Memory consumption reduced

· Capacity requirements reduced

· TLOG replication made easy

In WebLogic Server 12.1.3 “XA Transaction without Transaction Logs,” is restricted to transactions that involve a single Transaction Manager (WebLogic Server). The mixture of transactions that enlist determiner resources and span single Transaction Managers, with those who do not enlist a determiner resource and/or span multiple Transaction Managers is supported. In the future, WebLogic will support not logging transactions that involve multiple Transaction Managers.

Check out the YouTube recordings that go into detail how this feature works "JTA 12.1.3 New Feature and Optimization". There is even a demo that shows you how it is configured, how it works, and how you can debug your transactions to verify if the determiner is working "XA Transaction without Transaction Logs" and Demo.

Refer to the WebLogic Server 12.1.3 documentation JTA documentation "XA Transaction without Transaction Logs" for further details on how to configure and use the feature.

Monday Jun 30, 2014

Oracle WebLogic Server 12.1.3 Whitepaper - Developing with WebLogic Server

One of the most significant areas of investment in WebLogic Server 12.1.3 has been in developer productivity and API updates, as I summarized in my blog from last week.   However, a brief summary is typically not enough for developers who want a more detailed description of the improvements we have delivered.   And although product documentation contains all of the relevant updates, sometime it does not capture the overall background on the topic that puts the improvements into context.  

Steve Button from the WebLogic Server product management team has published an excellent whitepaper on OTN - Oracle WebLogic Server 12.1.3 Whitepaper - Developing with WebLogic Server - which provides a detailed description of the new features, along with the background which explains why we delivered the improvements, and the benefits they offer.   The whitepaper covers new WebLogic Server 12.1.3 features in the areas of WebSocket, JSON, JAX-RS, JPA, Server-Sent Events, Maven and more.

If you are a WebLogic Server user looking for a detailed description of the latest development features in WebLogic Server 12.1.3, and how you can leverage them in your applications, this is an excellent resource.   Please take a look!

Thursday Jun 26, 2014

Oracle WebLogic Server 12.1.3 is Released

We're proud to announce that Oracle WebLogic Server 12.1.3 has been released as part of the Cloud Application Foundation and Oracle Fusion Middleware 12.1.3 release as described at the Cloud Application Foundation Blog. Oracle WebLogic Server is the industry's leading application server, providing unparalleled choice for deploying applications in public clouds, on-premise private clouds, engineered systems such as Oracle Exalogic Elastic Cloud, Oracle SPARC SuperClusters, and Oracle Database Appliance systems, and conventional systems.

Oracle WebLogic Server 12.1.3 is a new version release of Oracle WebLogic Server 12c.   It builds on the features provided in WebLogic Server 12.1.2 to improve developer productivity, performance and high availability, and manageability.   It enables you to develop and deliver innovative applications, to meet the application service level requirements for your business, and to manage your application infrastructure efficiently to achieve low total cost of ownership.

For developers we have placed specific focus on enabling development of server applications that support rich client applications running in HTML5 browsers or mobile devices. Such applications typically rely on REST based Web Services, use JSON as the data format for message payloads, and often require dynamic updates between clients and servers. In Oracle WebLogic Server 12.1.3, we have implemented support for selected Java EE 7 APIs including JAX-RS 2.0, Java API for JSON Processing, Java API for WebSocket, and JPA 2.1, to enable and support development of such applications.  We have also delivered related value-added capabilities like support for Server-Sent Events and unique WebSocket emulation capability.

High availability and performance improvements include improvements to Oracle Database 12c integration support - we have bundled the latest version of the Oracle Database 12c driver for ready access to database integration features, and have certified Oracle Database 12c AQ JMS as a Foreign JMS Server within Oracle WebLogic Server.    Innovations to the Oracle WebLogic Server transaction processing subsystem enable elimination of transaction logs in many cases, increasing performance and simplifying distaster recover configuration.   Optimizations for Oracle Exalogic systems include JMS performance improvements, and Cooperative Memory Management to adapt server memory usage based on memory consumption on Oracle Exalogic systems.

Manageability enhancements include improvements to dynamic clusters introduced in Oracle WebLogic Server 12.1.2.   In Oracle WebLogic Server 12.1.3 we support use of whole server migration to provide improved availability for dynamic clusters environments using JMS.    We have expanded our support for REST-based management, adding lifecycle management, application deployment, and datasource configuration support via REST.   We have also made similar improvements to support for Oracle WebLogic Server management in Oracle Fusion Middleware Control.

Finally, Oracle WebLogic Server 12.1.3 is the foundation of the Oracle Fusion Middleware 12.1.3 release, which adds Oracle SOA Suite 12c and other Oracle Fusion Middleware products to the family of products that is supported with Oracle WebLogic Server 12c.  This will make it easy for Oracle WebLogic Server 12.1.3 customers to adopt the latest releases of these products, and will also enable Oracle Fusion Middleware users to take advantage of the latest features in WebLogic Server 12.1.3.  To learn more:

...and look for more information from us in the coming days and weeks.  Thanks!

Indian Government Organization Saves $125,000 with Real-Time Insight for Decision-Making

Chhattisgarh Infotech and Biotech Promotion Society (CHiPS) is run by the government of Chhattisgarh, which became India’s newest and tenth-largest state in November 2000. CHiPS deployed Oracle WebLogic Server Enterprise Edition with Oracle WebCenter products as well as Oracle Web Tier to automate document workflow processes and provide a consistent and transparent decision-making process to meet statutory requirements. It reduced paper and document management costs by US$125,000 in one year, extended visibility for decision-making processes, enhanced collaboration between departments, increased business productivity through anytime-anywhere access to information, and enhanced citizen satisfaction. For more details, read this customer snapshot.

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 Method) Source) Source) Source) Source)









java.sql.DriverManager.getConnection( 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

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.

Tuesday May 13, 2014

WebLogic 12c Distinctive Recipes: Architecture, Development and Administration

Dr. Frank Munz, one of our most esteemed Oracle Aces, has just released an updated book on Oracle WebLogic 12c, which contains more than 130 additional pages, half a dozen new webcasts and more than 16 new or rewritten recipes.
From the book abstract:
Imagine you need to know about a problem with your car's engine. You could plough through the 1000-page manual. Or you could chat to the mechanic over a cup of coffee. That's WebLogic 12c Advanced Recipes. It's WebLogic for software architects, administrators and developers. For people like you who know quite a bit about WebLogic. What you don't want is the typical 'recipe book' full of screenshots. Click here. Click there. Do this. Do that. That's WebLogic by numbers. What you really want are the things you won't find in the manual, like recommendations, discussions, best practices, deployable projects, webcast videos and directions on when to use a feature - and when not to. With all this and more, this book is the perfect complement to official courses and manuals. In short, this gem of a book is almost as good as attending one of Frank's renowned workshops.

Friday May 09, 2014

BA, the German federal employment agency, ensures labor market services availability and performance

Bundesagentur für Arbeit (BA), the German federal employment agency, is the leading provider of labor-market services in Germany. With more than 100,000 employees, BA is the largest German government agency and one of the largest employers in the country. Supporting more than 6 million customers and a rapidly growing IT department, BA needed an application infrastructure and management solution that could help to increase IT efficiency while decreasing complexity. To provide a comprehensive solution for its Oracle application platform, the agency decided to deploy Oracle WebLogic Server and Oracle Enterprise Manager. The combination provided BA with the availability, scalability, and performance to meet critical requirements, such as on-time job placements and compensation provisioning—while significantly reducing IT administration costs. Get more details from the recent BA case study and review their press release.

Thursday May 08, 2014

Reliance Commercial Finance Accelerates Time-to-Market, Improves IT Staff Productivity by 70%

Reliance Commercial Finance provides loans for real estate, commercial and private vehicles, construction equipment, and infrastructure to more than 70,000 customers, including businesses and individuals. The company has an operational presence that spans 66 locations in India, and it is one of the fasting growing nonbanking financial companies in the country.

With more than 2,000 users accessing the company’s core applications every day, the legacy IT infrastructure was struggling to process more than 6,000 daily transactions, especially during peak periods, such as the last five days of each month. It was also time-consuming and costly to manage and track customer-loan applications and approvals across multiple systems. The legacy system increased customer churn and time to market. 

To address these issues, the company implemented Oracle WebLogic Suite and Oracle Exalogic Elastic Cloud to ensure high-performance, high availability, and scalability for its core applications. It also enabled seamless integration with Oracle Exadata Database Machine. These implementations accelerated loan transaction speed by 30% and increased IT staff members’ productivity by 70%. In addition, the financial institution improved its competitiveness by accelerating the customer loan approval process by 3x and slashing new application deployments from eight weeks to one day, thereby increasing customer satisfaction. Complete details of Reliance Commercial Finance's use case can be found here.

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.

Monday Apr 28, 2014

Oracle, yet again, #1 in the Application Platform [previously known as Application Server] Market for 2013

Oracle takes the top spot for market share in the Application Platform Market Segment for 2013 according to the March 2014 Gartner “Market Share: All Software Markets, Worldwide 2013” report.

Supporting Resources

· For more information on the report, please contact Gartner Inc.

· Oracle WebLogic Server

· Oracle Fusion Middleware

· Oracle WebLogic Server blog

· Oracle WebLogic Server on OTN

· Connect with Oracle WebLogic Server via Facebook, Twitter and YouTube


The official blog for Oracle WebLogic Server fans and followers!

Stay Connected


« March 2015