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.


The official blog for Oracle WebLogic Server fans and followers!

Stay Connected


« July 2014 »