WebLogic JDBC
JDBC system resource is a J2EE specification, it is a interface between Java applications and ANY Database. which provides transaction support automatically for every query.
• Enable database connectivity using a dynamic pool of reusable connections
• are to be managed by the application server
• can be obtained by applications from the WebLogic Server's JNDI tree
Datasource configuration is stored in a XML file at/config/jdbc.
All WebLogic JDBC module files must end with the -jdbc.xml suffix, such as examples-demo-jdbc.xml.
Which WebLogic optimization allows one non-XA resource to participate in a distributed transaction?
JDBC system resource is a J2EE specification, it is a interface between Java applications and ANY Database. which provides transaction support automatically for every query.
Why do we need WebLogic Connection pool?
• Enable database connectivity using a dynamic pool of reusable connections
• are to be managed by the application server
• can be obtained by applications from the WebLogic Server's JNDI tree
Datasource configuration is stored in a XML file at
A Datasource object is used to establish connections. Although the Driver Manager can also be used to establish a connection, connecting through a Datasource object is the preferred method.
A Connection object controls the connection to the database. An application can alter the behavior of a connection by invoking the methods associated with this object. An application uses the connection object to create statements.
Statement, PreparedStatement, and CallableStatement objects are used for executing SQL statements. A PreparedStatement object is used when an application plans to reuse a statement multiple times. The application prepares the SQL it plans to use. Once prepared, the application can specify values for parameters in the prepared SQL statement. The statement can be executed multiple times with different parameter values specified for each execution. A CallableStatement is used to call stored procedures that return values. The CallableStatement has methods for retrieving the return values of the stored procedure.
A ResultSet object contains the results of a query. A ResultSet is returned to an application when a SQL query is executed by a statement object. The ResultSet object provides methods for iterating through the results of the query.
Database Transactions
- enabling pinned to thread
- enabling logging last resource
- increasing the statement cache size
- setting the statement cache type to LRU
- Configure multiple physical data sources and reuse the same JNDI name for each
- Use the compatibility option of Active GridLink to enable compatibility with non-Oracle database.
- Configure a single physical data source for each node in a database cluster and wrap it using multi data source.
- Configure a data source group that contains a physical connection pool to each node in the database cluster.
Keep posting your thoughts here...
What would be answer for this???????
Stay Tune to WebLogic 12c Administration Essentials Course available from Vybhava Technologies, Online, Inhouse, Corporate sessions....
< /h3>
How does JDBC work
A Datasource object is used to establish connections. Although the Driver Manager can also be used to establish a connection, connecting through a Datasource object is the preferred method.
A Connection object controls the connection to the database. An application can alter the behavior of a connection by invoking the methods associated with this object. An application uses the connection object to create statements.
Statement, PreparedStatement, and CallableStatement objects are used for executing SQL statements. A PreparedStatement object is used when an application plans to reuse a statement multiple times. The application prepares the SQL it plans to use. Once prepared, the application can specify values for parameters in the prepared SQL statement. The statement can be executed multiple times with different parameter values specified for each execution. A CallableStatement is used to call stored procedures that return values. The CallableStatement has methods for retrieving the return values of the stored procedure.
A ResultSet object contains the results of a query.
A ResultSet is returned to an application when a SQL query is executed by a statement object. The ResultSet object provides methods for iterating through the results of the query.
WebLogic JDBC
The WebLogic implementation of JDBC consists of the following component:Data sources:
- Enable database connectivity using a dynamic pool of reusable connections
- Are to be managed by the application server
- Can be obtained by applications from the WebLogic Server's JNDI tree
- Use a dynamic pool of reusable database connections
WebLogic Server can manage our database connectivity through JDBC data sources. Each data source that we configure contains a pool of database connections that are created when the data source instance is created—when it is deployed or targeted, or at server startup. The connection pool can grow or shrink dynamically to accommodate the demand.
Applications look up a data source on the Java Naming and Directory Interface (JNDI) tree or in the local application context (java:comp/env), depending on how we configure and deploy the object, and then request a database connection. When finished with the connection, the application uses the close operation on the connection, which simply returns the connection to the connection pool in the data source.
WebLogic Server data sources allow connection information, such as the JDBC driver, the database location (URL), and the username and password to be managed and maintained in a single location, without requiring the application to worry about these details. Datasource configuration is stored in a XML file at
WebLogic JDBC drivers
The WebLogic Type 4 JDBC drivers are installed with Oracle WebLogic Server in the
WebLogic Server's JNDI architecture
The diagram shows the flow between a database and a Java application through API drivers. The JDBC specification defines an interface for Java programs to use and an interface for which database vendors can develop custom drivers. Application developers will have to learn only a single JDBC API. The JDBC API is designed to work with any JDBC driver. Any proprietary driver that is developed by a database vendor will be compatible with a JDBC program.
Oracle implements two types of JDBC drivers:
- Thick JDBC drivers built on top of the C-based Oracle Net client
- Thin (pure Java) JDBC driver to support downloadable applets WebLogic supports Oracle’s thin drivers. Related to JDBC is the Java Persistence API (JPA), which provides object-to-relational persistence architecture for storing Java objects and Enterprise Java Beans (EJBs) in relational database tables.
The diagram shows the programming layers and API interfaces for managing named objects. Naming and directory services are used to hierarchically structure items that need to be made available to distributed programs. Naming and directory services provide lookup, search, and binding features to their clients. Clients can navigate the trees and contexts of a naming or directory service in search of the object they require. A variety of naming and directory services are available JNDI (pronounced “jenn-dee”) is an API and a standard that Java programs use to access existing naming or directory services. It is not a naming or directory service. It is merely the mapping. Different naming and directory services store objects in different ways. Oracle WebLogic Server has its own proprietary naming service that it uses to store configurable Java objects. Client programs connect to the naming service and download various Java objects that they need to use. In Oracle WebLogic Server, JNDI serves as a repository and lookup service for Java EE objects, including:
• Enterprise JavaBeans (EJB) home stubs
• JDBC data sources
• JMS connection factories, queues, and topics
• Remote Method Invocation (RMI) stubs
JNDI Tree The terms associated with a JNDI tree include the following:
• Context: A node in the JNDI tree. It can contain only a list of objects and contexts
. • Object: A leaf in the JNDI tree, which is bound to a context. It cannot contain other objects or contexts.
• Root context: The context at the top in the entire tree
• Initial context: A context that is chosen as the starting point for all future operations.
This is somewhat like the “current directory” that you choose. It does not always have to be the root context of your directory structure. The initial context is merely the starting point that you select to traverse through the application. Take a look at object O3 in the diagram in the slide. You bind it to two contexts: A and B. Does the object that is bound to two different contexts exist once or twice in the naming service? Or, worded differently, is the object accessed by value or by reference? The answer is that JNDI stores objects by value, copying them into the tree.
That is, there are multiple copies in the tree. To create a “by reference” binding, you need to use the LinkRef class. JNDI Contexts and Sub contexts
• Subcontexts are referenced through dot or slash delimiters (. Or/).
• Subcontexts must be created before objects are placed into them.
• Typically, when objects are bound to a JNDI tree, subcontexts are automatically created based on the JNDI name.
• Example: If the following context exists: com.oracle.examples You cannot bind: com.oracle.examples.ejb.SomeObject Without first creating: com.oracle.examples.ejb3
A transaction manager or transaction processing monitor (TP monitor), coordinates the transactions across multiple resources such as databases and message queues. Each resource has its own resource manager. The resource manager typically has its own API for manipulating the resource, for example the JDBC API used by relational databases. In addition, the resource manager allows a TP monitor to coordinate a distributed transaction between its own and other resource managers. Finally, there is the application which communicates with the TP monitor to begin, commit or rollback the transactions.
Comparing different types of data sources
WebLogic 12c provides three types of data sources which are 1. Generic data source 2. Multi data source 3. Grid link data source Generic data source Multi data source Grid link data source It is a single data source which provides connection to one database from WebLogic server It is a group of multiple Generic data sources which provides more than one database connection to WebLogic server. It is a data source which provides connection to only RAC data base from WebLogic server which is a Cluster databaseComparing the different data source transaction options
When We configure a JDBC data source using the Administration Console, WebLogic Server automatically selects specific transaction options based on the type of JDBC driver: • For XA drivers, the system automatically selects the Two-Phase Commit protocol for global transaction processing. • For non-XA drivers, local transactions are supported by definition, and WebLogic Server offers the following options Supports Global Transactions: (selected by default) Select this option if you want to use connections from the data source in global transactions, even though you have not selected an XA driver. When you select Supports Global Transactions, you must also select the protocol for WebLogic Server to use for the transaction branch when processing a global transaction: • Logging Last Resource: With this option, the transaction branch in which the connection is used is processed as the last resource in the transaction and is processed as a local transaction. Commit records for two-phase commit (2PC) transactions are inserted in a table on the resource itself, and the result determines the success or failure of the prepare phase of the global transaction. This option offers some performance benefits and greater data safety than Emulate Two-Phase Commit, but it has some limitations. • Emulate Two-Phase Commit: With this option, the transaction branch in which the connection is used always returns success for the prepare phase of the transaction. It offers performance benefits, but also has risks to data in some failure conditions. Select this option only if your application can tolerate heuristic conditions • One-Phase Commit: (selected by default) with this option, a connection from the data source can be the only participant in the global transaction and the transaction is completed using a one-phase commit optimization. If more than one resource participates in the transaction, an exception is thrown when the transaction manager calls XAResource.prepare on the 1PC resource.Create and configure a generic data source
Data source can be configured in two ways1. WLST
2. Admin console
Data source creation from Admin console
1. Click on data sources in services
2. Click on New to select type of data source as Generic data source and give the data source name and jndi name. Select type of the database.
3. Select Database driver name according to requirement
4. Select required transaction options
5. Assign the Database details like username , password and IP address and click on next.
6. Click on Test configuration which verifies the data base details are valid or not.
7. Select the target
8. Click on finish and see the created data source.
9. Go to the terminal and execute the simplesql.java program to create the employee table through the WebLogic datsource
Vi Simplesql.java
• Edit the program according to WebLogic admin url and data source jndi name
• Compile and execute the program as below
Javac –d SimpleSql.java
Java vybhava.technologies.jdbc.SimpleSql
Some advanced settings
Here are some of these settings explained:• Initial Capacity: This is the number of physical connections to create when deploying the connection pool.
\ • Maximum Capacity: This is the maximum number of physical connections that this connection pool can contain. For optimal performance, set the value of Initial Capacity equal to the value for Maximum Capacity. Be aware that this disables the dynamic resizing.
• Capacity Increment: When there are no more available physical connections to satisfy ch3/>onnection requests, Oracle WebLogic Server creates this number of additional physical connections and adds them to the connection pool up to the maximum capacity.
• Test Frequency: This is the time in seconds that Oracle WebLogic Server tests the unused connections. This requires that you specify a Test Table Name. In an Oracle database, you could use DUAL for this purpose. Monitoring and testing a Data Source you can monitor it in the Administration Console. Locate and select your new Data Source and click on Monitoring | Statistics tab. Statistics are displayed for each deployed instance of the Data Source. Optionally, click Customize this table to change the columns displayed in the Statistics table. For example, some of the available columns (not displayed by default) include:
\• Active Connections Current Count: The number of connections currently in use by applications
• Active Connections Average Count: The average number of active connections from the time that the data source was deployed
• Connections Total Count: The cumulative total number of database connections created in this Data Source from the time the Data Source was deployed
• Current Capacity: The current count of JDBC connections in the connection pool in the Data Source
• Highest Num Available: The highest number of database connections that were available at any time in this instance of the Data Source from the time the Data Source was deployed
• Waiting for Connection High Count: The highest number of application requests concurrently waiting for a connection from this instance of the Data Source
Connection pool
Oracle WebLogic Server opens JDBC connections to the database during the WebLogic startup process and adds the connections to the pool. This is faster than creating a new connection on demand. The size of the pool is dynamic and can be fine-tuned.
Usually, making a DBMS connection is a very slow process. When Oracle WebLogic Server starts, connections from the connection pools are opened and are available to all clients. When a client closes a connection from a connection pool, the connection is returned to the pool and is available for other clients; the connection itself is not closed. There is little cost in opening and closing pool connections.
No comments:
Post a Comment