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.


 

OpenWorld Session: Intelligent Integration - WebLogic & Active GridLink for RAC

Oracle WebLogic Active GridLink for RAC is the market-leading mid-tier integration solution leveraging additional Oracle RAC advancements. Oracle and NEC have jointly invested on verifying and testing the Active GridLink for RAC solution implemented within Oracle WebLogic Server which provides high-availability, scalability and high performance solution for helping customer building mission critical applications. In this session, we will discuss the detailed Active GridLink capabilities and the testing results done by NEC. We then will introduce the new functionality on Oracle Database 12c integration.

Please come to meet our experts from Oracle and NEC discussing the latest and greatest technologies; and learn how this will benefit your business!

Session ID: CON8977

Time: Wed, Sept 25, 1:15-2:15pm
Location: Marriott Marquis, Room Golden Gate A

Speakers: Naoto Kashiwagi (NEC), Frances Zhao-Perez (Oracle), Yosuke Arai (Oracle) 

Read the join whitepaper written by NEC and Oracle on this topic.

Monday Sep 16, 2013

Ensuring high level of performance with WebLogic JDBC

In this post you will find some common best practices aimed at ensuring high levels of performance with WebLogic JDBC.  However, rather than just throwing some tips, I will detail why each recommendation is beneficial to JDBC and Weblogic Server performance.

  • Use Oracle JDBC thin driver (Type 4) rather than OCI driver (Type 2)

The Oracle JDBC thin driver is lightweight (easy to install and administrate), platform-independent (entirely written in Java), and provides slightly higher performance than the JDBC OCI (Oracle Call Interface) driver.  The thin driver does not require any additional software on the client side.  Oracle JDBC FAQ stipulates that the performance benefit with the thin driver is not consistent and that the OCI driver can even deliver better performances in some scenarios.

  • Use PreparedStatements objects rather than Statement 
With PreparedStatements, compiled SQL statements will be kept in cache and only be executed once against the database.  As a result, unnecessary parsing and round-trips to the database will be avoided when the same statement is used later within the same connection.  The statement cache size defines the total number of prepared statement that can be made with a single connection from the Datasource.

  • Close all JDBC resources in a finally Block

This include ResultSet, Connection, Statement and Prepared Statement objects and to avoid potential memory leaks.  The connection.close() won't necessarily automatically clean up all the other objects because the implementation of close() may differ between JDBC drivers.  Also, JDBC objects not properly closed could lead to this error:

java.sql.SQLException: ORA-01000: maximum open cursors exceeded.

If you don't explicitly close Statements and ResultSets right away, cursors may accumulate and exceed the maximum number allowed in your DB before the Connection is closed. 

  • Set Shrink frequency to 0 in production environments

By disabling Shrink frequency you will not allow waits before shrinking a connection pool that has incrementally increased to meet demand.  The Shrink Frequency parameter is used to specify the number of seconds to wait before shrinking a connection pool, given that ShrinkingEnabled is kept at its default value, or set to true.  Weblogic shrinks a connection pool by reducing the number of connections to the greater of either the minimum capacity or the number of connection in use and thus frees up some resources.  In development we can afford to keep the no-longer-used connection active rather than immediately returning them to the pool.  

  • Consider skipping the SQL-query test when Test Connections on Reserve is enabled

When Test Connections on Reserve is enabled (see Advanced Connection Pool Configuration in the console), the Weblogic Server checks a database connection prior to returning the connection to a client to avoid passing an invalid connection in the application.  Since this operation could impact the performance, it's recommended to use Seconds to Trust an Idle Pool Connection (set to 10 seconds by default) that defines how long WebLogic Server will trust the connection and therefore skip the connection test after a connection has been proven valid.

  • Enable Pinned-to-Thread
Disabled by default, this option can improve performance by enabling threads to keep a pooled database connection even after the application closes the logical connection.  This eliminates potential contention between threads getting a database connection.  However, this parameter should be used with great care because the connection pool maximum capacity is ignored when pinned-to-thread is enabled.  A connection no longer used will not return to the pool but will stay linked to the thread, and no shrinking can apply to that pool.
  • Ensure that Maximum Thread Constraint property doesn't exceed the number of database connection

This property (See Environment Work Manager in the console) will set a maximum number of possible concurrent requests. If it exceeds the number of database connection then some threads might end up waiting until existing database connection are made available.


Visit Tuning Data Source Connection Pools and Tuning Data Sources for additional parameters tuning in JDBC data sources and connection pools to improve system performance with Weblogic Server 12.1.2, and Performance Tuning Your JDBC Application for application-specific design and configuration. 

Therap Services at OpenWorld: Highlights Support for Individuals with Developmental Disabilities

Therap Services, LLC. is a web-based service organization that provides an integrated solution for documentation, reporting and communication needs of agencies providing support to people with developmental disabilities. It offers an easy and efficient alternative to the immense amount of paper work that is done manually by the care providers. Therap’s software suite is relevant to all the different kinds of service organizations that support and care for people with intellectual and developmental disabilities. Therap is used in over 1,000 agencies, in small agencies serving as few as one individual to multi-state providers serving thousands of individuals. The modules can be categorized under Individual Support, Staff Support and Billing and Attendance Support. Therap uses Oracle Database and had been using JBoss as the application server for their mission critical application.  As Therap has grown, they have experienced several performance issues with JBoss – specifically problems with JBoss Messaging.  As Therap continues to expand their business, they felt the need for a more robust solution for their core business application.  Additionally, Therap needed a more advanced monitoring solution for both internal and external transactions on multiple layers:  application, database, application server. They chose Oracle WebLogic Server for three main reasons:  1) Extremely high confidence level in the Oracle Product Management team expertise, 2) Access to a better support system with product integration and best practices, and 3) Oracle’s proven reliability history.  Come join Therap Services CTO Masum at OpenWorld to hear about how Therap leverages Oracle WebLogic Server with Oracle Enterprise Manager to really take their applications to the next level. In addition, while at OpenWorld don’t miss other Cloud Application Foundation Innovators. You can join the session whether you are an OpenWorld attendee or not.

Wednesday Sep 11, 2013

WebLogic Server and PDB Switching with Oracle Database 12.1

Oracle WebLogic Server 12c (12.1.2) has integrated to support the Oracle Database 12c features, particularly Application Continuity, Transaction Guard, Database Resident Connection Pool, Multi Tenant Databases, and Global Data Services. WLS integration to these new 12c database features is described in this blog

https://blogs.oracle.com/WebLogicServer/entry/new_whitepaper_cloud_performance_elasticity.

The integration to Multi Tenant Database or Pluggable Database increases elasticity, scalability, and enables multitenancy. Pluggable Database implementations allow multiple distinct databases in a single, larger database installation. The Container Database (CDB) feature in Oracle Database 12c minimizes the overhead of these multi-database configurations by consolidating them into a single database with multiple Pluggable Databases (PDB) in a single Container Database. For more information about using this feature in WLS, see https://blogs.oracle.com/WebLogicServer/entry/part_3_12c_database_and

You should be aware of some limitations of PDB switching with Oracle Database 12.1. The following WebLogic Server limitations exist when using tenant switching.

  • FAN is not supported. Even though FAN is not supported, Active GridLink still provides the benefit of a single datasource view of multiple RAC instances and the ability to reserve connections on new instances as they are available without reconfiguration using connection load balancing. If you want to use tenant switching with an Active GridLink data source, “FAN enabled” must be set to false see http://docs.oracle.com/middleware/1212/wls/JDBCA/gridlink_datasources.htm#CHDIAGEF . Generic data sources don’t use FAN so this restriction doesn’t apply.

  • DRCP is not supported

  • Application continuity is not supported.

  • Proxy authentication is not supported.

  •  XA transactions in one datasource configuration with PDB switching is not supported.

For more details about these limitations read the documentation http://docs.oracle.com/middleware/1212/wls/JDBCA/ds_oracledriver.htm#JDBCA655.

Friday Sep 06, 2013

Announcing new MAA paper - Oracle Traffic Director Disaster Recovery!

The MAA paper covering Disaster Recovery for Oracle Traffic Director is available on OTN:
http://www.oracle.com/technetwork/database/availability/maa-oracletrafficdirector-dr-2008165.pdf

Please check it out!

This paper describes the disaster recovery solution for Oracle Traffic Director based on Oracle MAA architecture principles.

Oracle Traffic Director is a fast, reliable, and scalable layer-7 software load balancer that you can deploy as the reliable entry point for all TCP, HTTP and HTTPS traffic to application servers and web servers in your network.

http://www.oracle.com/us/products/middleware/application-server/oracle-traffic-director-ds-1389582.pdf

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.

About

The official blog for Oracle WebLogic Server fans and followers!

Stay Connected

Search

Archives
« September 2013 »
SunMonTueWedThuFriSat
1
2
3
4
7
8
9
10
12
13
14
15
17
18
19
21
22
23
24
25
26
27
28
29
30
     
       
Today