This is in continuation of my last post on Database Connectivity (JDBC) in WebLogic Server, In today’s post I am going to cover step by step JDBC configuration using Administration Console. Login to WebLogic Server Administration console (default port 7001) 2. Select Data Sources under JDBC in Services section. Click on New button on right side as shown above 4. Enter JDBC Name, JNDI Name, Database & Driver type as shown below. In next screen, enter database connection pool details i.e. — Database Name — Host Name (on which database is running) — PortNumber (on which database listener is listening) — Database User Name & — Password (for database user).
How to Connect to WebLogic DataSource from a Java Client? Guest Author Some time ago, one of my customers had issues connecting from a client to a WebLogic Datasource.
![T4Cconnection T4Cconnection](https://helpcenter.veeam.com/evaluation/backup/hyperv/en/images/em_decrypt_responce_hv.png)
In next screen you test connection by clicking on “ Test Configuration” as shown below. 7.Finally you select target servers (Administration and Managed Server in that domain) for that Datasource. On clicking Finish button, you should see datasource as listed below. To create Multi Datasource Steps mentioned above are to create single Datasource. To create Multi Datasource first create two or more Datasource as mentioned above (I created JDBC1 & JDBC2) then select Multi Datasources from console as shown below. Click on New button above, In next screen select Name of Multi Datasource and JNDI. Select Algorithm Typefor Multi Datasource i.e.
Failover or Load Balancing 4. Select Datasource which you want to make part of Multi Datasource as shown below. Finally click on Finish to see Multi Data Sources JDBC tuning in WebLogic and lot more coming soon Did you get a chance to download Free Interview Questions related to WebLogic? If not, download it here. Arungoin says May 16, 2010 Hi Atul, A nice intro on data source configuration.
Thank you, by the way we are facing one problem from OC4J time, i.e. Changing password of data source user mandates server restart, is it possible to get ride of this. I tried Datasource - Control Shutdown/ Start but still no hope. Thanks Arunachalam.C Lead Consultant BPEL Emaar Business Park, Building 3, Level 4 IT Department, PO Box 9440, Dubai, United Arab Emirates Direct tel: + 971 4 3673878 Mobile: + 908. Paul says May 28, 2010 Hi Atul, This is good doc. Thanks for taking efforts to put this together.
I have a question: I am trying to to connect from OmniPortlet to SQL Server database. I think, I have to register the database driver in provider.xml. But when I search for this file, I see many provider.xml files in middleware home. The doc says modify the file from “OmniPortletWARDIRECTORY/WEB-INF/providers/omniPortlet” directory. Do you know exactly which provider.xml to modify. I am looking for exact file location on windows server.
Thanks for your time.
Accessing a closed JDBC object is a common application error that can be difficult to debug. To help diagnose such conditions there is a new profiling option to generate a diagnostic log message when a JDBC object (Connection, Statement or ResultSet) is accessed after the close method has been invoked. The log message will include the stack trace of the thread that invoked the close method. To enable closed JDBC object profiling, the datasource ProfileType attribute bitmask must have the value 0x000400 set.
This is a WLST script to set the value. # java weblogic.WLST prof.py import sys, socket, os hostname = socket.gethostname datasource='ds' svr='myserver' connect('weblogic','welcome1','t3://'+hostname+':7001') # Edit the configuration to set the leak timeout edit startEdit cd('/JDBCSystemResources/' + datasource + '/JDBCResource/' + datasource + '/JDBCConnectionPoolParams/' + datasource ) cmo.setProfileType(0x000400) # turn on profiling save activate exit In the administrative console on the Diagnostics Tab, this may be enabled using the Profile Closed Usage checkbox. The closed usage log record contains two stack traces, one of the thread that initially closed the object and another of the thread that attempted to access the closed object. An example record is shown below. #### When this profiling option is enabled, exceptions indicating that an object is already closed will also include a nested SQLException indicating where the close was done, as shown in the example below.
Java.sql.SQLException: Connection has already been closed. At weblogic.jdbc.wrapper.PoolConnection.checkConnection(PoolConnection.java:82) at weblogic.jdbc.wrapper.Connection.preInvocationHandler(Connection.java:107) at weblogic.jdbc.wrapper.Connection.createStatement(Connection.java:582) at Application.doit(Application.java:156). Caused by: java.sql.SQLException: Where closed: ThreadACTIVE ExecuteThread.
At weblogic.jdbc.common.internal.ProfileClosedUsage.saveWhereClosed(ProfileClosedUsage.java:32) at weblogic.jdbc.wrapper.PoolConnection.doClose(PoolConnection.java:239) at weblogic.jdbc.wrapper.PoolConnection.close(PoolConnection.java:154) at Application.doit(Application.java:154). This is very helpful when you get an error indicating that a connection has already been closed and you can't figure out where it was done. Note that there is overhead in getting the stack trace so you wouldn't normally run with this enabled all the time in production (and we don't default to it always being enabled), but it's worth the overhead when you need to resolve a problem.