You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Brad Rhoads <br...@zethcon.com> on 2005/01/06 20:29:10 UTC
RESOLVED: Tomcat To Oracle Connection [ RE: Oracle 9i client connection to 8i database]
Using this connection string does the trick:
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)))(HOST=
host)(PORT=port)(CONNECT_DATA=(SERVICE_NAME=sid)(SERVER=DEDICATED)))
I was missing the SERVER=DEDICATED before.
Note that this solved my problem even though we are not using MTS as
expected by the following article. And we are using explicit IP everywhere
so I'm not sure the root cause was what they suggest here.
<http://metalink.oracle.com/images/metalink/generic/usaeng/kur_left_top.gif>
<http://metalink.oracle.com/images/metalink/generic/usaeng/kur_right_top.gif
>
<file:///C:/Documents%20and%20Settings/brhoads/Local%20Settings/Temporary%20
Internet%20Files/OLK16F/ml2_bookmarks.addBookmark?p_title=JDBC%20Connection%
20Failure%3A%20Network%20Adapter%20Could%20not%20Establish%20Connection&p_da
tabase_id=NOT&p_document_id=139775.1&p_username=BDETERLING> Bookmark
<file:///C:/Documents%20and%20Settings/brhoads/Local%20Settings/Temporary%20
Internet%20Files/OLK16F/ml2_documents.showNot?p_id=139775.1&p_font=> Fixed
font
<file:///C:/Documents%20and%20Settings/brhoads/Local%20Settings/Temporary%20
Internet%20Files/OLK16F/139775.html#bottom> Go to End
Doc <file:///C:/help/usaeng/Search/search.html#file> ID:
Note:139775.1
Subject: JDBC Connection Failure: Network Adapter Could not Establish
Connection
Type: PROBLEM
Status: PUBLISHED
Content Type: TEXT/PLAIN
Creation Date: 13-APR-2001
Last Revision Date: 09-NOV-2004
PROBLEM
-------
You are attempting to connect to an Oracle instance using JDBC
and you are receiving the following error.
java.sql.SQLException: Io exception:
The Network Adapter could not establish connection
SQLException: SQLState (null) vendor code (17002)
Any or all of the following conditions may also apply:
1) You are able to establish a SQL*Plus connection from the same
client to the same Oracle instance.
2) You are able to establish a JDBC OCI connection, but not a Thin
connection from the same client to the same Oracle instance.
3) The same JDBC application is able to connect from a different
client to the same Oracle instance.
4) The same behavior applies whether the initial JDBC connection
string specifies a hostname or an IP address.
REDISCOVERY
-----------
To verify whether you are hitting this problem, verify whether the
Oracle instance is configured for Multithreaded Server (MTS).
If the Oracle instance is not configured for MTS, you are probably
encountering a different problem. Otherwise, continue.
Try forcing the JDBC connection to use a dedicated server instead
of a shared server. This can be accomplished in several ways.
For JDBC OCI or Thin, this can be done by reconfiguring the server
for dedicated connections only. This approach, however, may not be
feasible in many cases. In such cases, the following options apply:
For JDBC OCI:
1) Add the (SERVER=DEDICATED) property to the TNS connect string
stored in the tnsnames.ora file on the client.
2) Set the user_dedicated_server=ON in sqlnet.ora on the client.
For JDBC Thin:
You must specify a full name-value pair connect string (the same
as it might appear in the tnsnames.ora file) instead of the short
JDBC Thin syntax. For example, instead of
"jdbc:oracle:thin:@host:port:sid"
you would need to use a string of the form
"jdbc:oracle:thin:@(DESCRIPTION=" +
"(ADDRESS_LIST=" +
"(ADDRESS=(PROTOCOL=TCP)" +
"(HOST=host)" +
"(PORT=port)" +
")" +
")" +
"(CONNECT_DATA=" +
"(SERVICE_NAME=sid)" +
"(SERVER=DEDICATED)" +
")" +
")"
If the connection works fine after having made these changes, it
is very likely that this is the problem you are encountering. In
this case, one last test will help to verify this fact.
Log into the remote host on which the Oracle instance is running
and execute the appropriate command to determine what the server
'thinks' its hostname is (i.e. the name that was configured when
the server was installed and configured). For example, on a Unix
host the 'hostname' command can be used for this purpose.
Using the name displayed (e.g. by the hostname command), exactly
as it appeared (i.e. if the output from the hostname command had
the domain name included, then include it), return to the client
which was unable to connect and try pinging the server.
NOTE: It is critical that you attempt to ping the server using
EXACTLY the same hostname you got from the server.
If you are unable to ping the server via this hostname, then you
almost certainly hitting this problem. If not, this may be a new
issue, but at least you will have found a workaround (i.e. use a
dedicated connection).
EXPLANATION
-----------
To understand why this
problem occurs, one must first understand
the differences in how the listener handles connections to shared
servers versus dedicated servers.
When connecting to a dedicated server, the client connects to the
listener (via hostname or IP address). The listener then spawns a
dedicated server process and hands off the socket used to accept
the client connection to that server. The client and server then
start communicating via the endpoints established by the initial
connection. NOTE: There is only one connection in this case.
When connecting to a shared server, the initial client connection
to the listener is the same. However, with MTS, there is no need
to spawn a new server process; a pool of shared processes already
exists. Also, clients do not communicate directly with the server
processes in MTS; rather, they communicate with a dispatcher.
For this reason, when setting up an MTS connection, the listener
sends a redirect message back to the client asking the client to
close the connection to the listener and connect to a dispatcher.
The information in this message includes the hostname and a port
number for the appropriate dispatcher. The redirect message will
ALWAYS specify a hostname, even if the client initially provided
an IP address.
If, for any reason, the hostname provided to the listener (e.g. by
the 'hostname' or another command) doesn't agree with the hostname
by which the server is known on the client, the connection fails.
On the other hand, if "(SERVER=DEDICATED)" already appears in the
TNS connect string in tnsnames.ora or if "use_dedicated_server=ON"
already appears in the sqlnet.ora file, you may find that SQL*Plus
and/or JDBC OCI work fine, while JDBC Thin fails.
SOLUTION
--------
Obviously, one solution is to use dedicated servers. However, this
may not always be feasible.
The key is to make sure the hostname on both the client and server
ag
ree. This can be accomplished by reconfiguring either the client
or the server, but there are things to be aware of in both cases.
If the server is configured to return a different hostname, then it
is possible that other clients which used to work will now fail.
In some cases, it may not be feasible to reconfigure the client. For
example, if the server version of the hostname does not include the
domain, you would need to remove the domain portion of the hostname
on the client; but, if the client needs to connect to more than one
server with the same base name in different domains, this may not be
possible, as the hostname may be ambiguous.
REFERENCES
----------
bug:1269734
<file:///C:/Documents%20and%20Settings/brhoads/Local%20Settings/Temporary%20
Internet%20Files/OLK16F/ml2_documents.showDocument?p_id=1269734&p_database_i
d=BUG> java.sql.SQLException: Io exception: The Network Adapter could not
<<End_of_Article>>
FOLDER:languages.Java.JDBC
TOPIC:Known Problems
DOCUMENT-ID:139775.1
ALIAS:
SOURCE:ADHOC
DOCUMENT-TYPE:PROBLEM
TITLE:JDBC Connection Failure: Network Adapter Could not Establish
Connection
IMPACT:LOW
SKILL-LEVEL:NOVICE
STATUS:PUBLISHED
DISTRIBUTION:EXTERNAL
ZCXPUBLIC ZCXREVIEWED
AUTHOR:BHBAILEY.US
PRODID-972 COMPONENT:OCI MINVER: MAXVER:
PRODID-972 COMPONENT:THIN MINVER: MAXVER:
PORTID-GENERIC
.
_____
<http://metalink.oracle.com/images/metalink/generic/usaeng/kur_left_bottom.g
if> Copyright (c) <http://www.oracle.com/html/copyright.html> 1995,2000
Oracle Corporation. All Rights Reserved.
<http://metalink.oracle.com/metalink/plsql/ml2.show_legal_text> Legal
Notices and Terms of Use.
<http://metalink.oracle.com/images/metalink/generic/usaeng/kur_right_bottom.
gif>
> -----Original Message-----
> From: Phillip Qin [mailto:Phillip.Qin@shareowner.com]
> Sent: Tuesday, January 04, 2005 3:39 PM
> To: 'Tomcat Users List'
> Subject: RE: Oracle 9i client connection to 8i database
>
> There is nothing to do with Oracle client. All you need is
> the jdbc driver.
>
> -----Original Message-----
> From: Brad Rhoads [mailto:brad@zethcon.com]
> Sent: December 27, 2004 5:11 PM
> To: 'Tomcat Users List'
> Subject: RE: Oracle 9i client connection to 8i database
>
>
> I always assumed the Oracle client was required. . .
>
> I uninstalled the client and get the same results. With the
> sid syntax I at
> least get an entry in the listener.log:
>
> 27-DEC-2004 16:58:11 *
> (CONNECT_DATA=(SID=test)(CID=(PROGRAM=)(HOST=__jdbc__)(USER=or
> acle))) *
> (ADDRESS=(PROTOCOL=tcp)(HOST=10.0.0.4)(PORT=33244)) * establish *
>
> But the app doesn't get a connection. And with the
> service_name syntax I
> only get a connection error:
>
> DatabaseMessageresources: Loading all the messages for the messageMap
> NVFactory: _readNVPair expected )
> DatabaseMessageresources: SQL EXCEPTION FETCHING MESSAGE
> java.sql.SQLException: Io exception: NL Exception was generated
> at
> oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:187)
>
> I've run into a similar problem where the db server was
> behind the firewall
> and the firewall didn't allow high-ports, but in this case
> both machines are
> behind the firewall.
>
> Any other ideas why I might not be able to get a connection?
>
> > -----Original Message-----
> > From: Michael Echerer [mailto:mech@tngtech.com]
> > Sent: Saturday, December 25, 2004 4:08 AM
> > To: Tomcat Users List
> > Subject: Re: Oracle 9i client connection to 8i database
> >
> > How come that you need an Oracle client installation at all
> > when you just want to use the Oracle thin JDBC driver? IHMO
> > the client installation is only required for OCI thick drivers...
> >
> > Brad Rhoads wrote:
> > > We have an (struts) app that talks to an Oracle 8i database. Our
> > > latest installation wants to run the app on Fedora Core 2.
> > I couldn't
> > > get the Oracle 8i client install, so I installed the 9i
> > client. With
> > > the 9i client, you have to use a service_name instead of a
> > sid in the connection.
> > >
> > > Normally my connection string (in my web.xml) looks like:
> > >
> > > <param-value>jdbc:oracle:thin:@10.0.0.7:1521:test</param-value>
> > >
> > > But it seems to get a service_name instead of a sid I have to use
> > > something
> > > like:
> > >
> > >
> > >
> >
> <param-value>jdbc:oracle:thin:@jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS
> > > =(PROT
> > >
> >
> OCOL=TCP)(HOST=10.0.0.7)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=test))
> > > )</par
> > > am-value>
> > >
> > > My problem is I'm getting this error:
> > >
> > > NVFactory: _readNVPair expected
> > >
> > > It doesn't seem to make any difference if I use the 8i or
> > the 9i drivers.
> > >
> > > I've also tried
> > >
> > >
> > <param-value>jdbc:oracle:thin:@//10.0.0.7:1521/test</param-value>
> > >
> > > But that just gave me a format error.
> > >
> > > I can connect fine using sqlplus.
> > >
> > > What am I doing wrong?
> > >
> > > Thanks for the help. Merry Christmas!
> > >
> > >