Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #38248 > unrolled thread

(jdbc) Universal Connection Pool with wallet...

Back to article view | Back to comp.lang.java.programmer

Contents

  (jdbc) Universal Connection Pool with wallet... Andreas Leitgeb <avl@logic.at> - 2018-04-18 14:49 +0000
    Re: (jdbc) Universal Connection Pool with wallet... Sebastian <nowhere@nirvana.org> - 2018-04-19 19:55 +0200
      Re: (jdbc) Universal Connection Pool with wallet... Andreas Leitgeb <avl@logic.at> - 2018-04-20 07:12 +0000
        Re: (jdbc) Universal Connection Pool with wallet... Andreas Leitgeb <avl@logic.at> - 2018-10-17 13:18 +0000

#38248 — (jdbc) Universal Connection Pool with wallet...

We're in progress of upgrading the Oracle Database version for our
application from 11.2... to 12.1.0.2

Most of our application's database-connections are handled through
Oracle's Universal Connection Pool (ucp.jar), and the connections
make use of a wallet for user/password information.

With 12.1.0.2, our application only gets this exception:
 oracle.ucp.UniversalConnectionPoolException: Failed to create
    initialPoolSize connections while starting a pool

Some debugging (using the _g variant of ojdbc6.jar) revealed a reason
for the empty pool:  While the user name and password from the wallet
*do* show up in the trace, they apparently aren't used to create
the connections for the pool's initial fill. The connection attempt
apparently fails for the unset user and password (and setting them to
empty strings still fails, just slightly differently: with an ORA-01017
also only visible in the trace log)

If I explicitly provide user&password using setUser() and setPassword()
on the pool, then it all works, but I really need it to use the wallet.

Anyone else hit by that problem?

PS: Trying 12.2 isn't an option for me, except if there's a official
  (and quote-able) statement from Oracle that  wallet&UCP wouldn't ever
  work together in 12.1 ...

[toc] | [next] | [standalone]

#38250

Am 18.04.2018 um 16:49 schrieb Andreas Leitgeb:
 > We're in progress of upgrading the Oracle Database version for our
 > application from 11.2... to 12.1.0.2
 >
 >[snip]
 >
 > Some debugging (using the _g variant of ojdbc6.jar) revealed a reason
 >[snip]
I know nothing about wallets, but I have had other problems with those 
old drivers from ojdbc6.jar. Are you still on Java 6? If not, you could 
try using the newer drivers version 12.1.0.2 from ojdbc7.jar or version 
12.2.0.1 from ojdbc8.jar. With any luck that might perhaps already solve 
your problem.

-- Sebastian

[toc] | [prev] | [next] | [standalone]

#38251

Sebastian <nowhere@nirvana.org> wrote:
> Am 18.04.2018 um 16:49 schrieb Andreas Leitgeb:
> > We're in progress of upgrading the Oracle Database version for our
> > application from 11.2... to 12.1.0.2
> >[snip]
> > Some debugging (using the _g variant of ojdbc6.jar) revealed a reason
> >[snip]
> I know nothing about wallets, but I have had other problems with those 
> old drivers from ojdbc6.jar. Are you still on Java 6? If not, you could 
> try using the newer drivers version 12.1.0.2 from ojdbc7.jar or version 
> 12.2.0.1 from ojdbc8.jar. With any luck that might perhaps already solve 
> your problem.

Well, we're still stuck on Java7 (until customer *wants* Java8)
That's why 12.2.* is still out of reach for us.

But I did try ojdbc7 in the meantime (compiling and running),
and it shows the same problem.

I've got a testcase using oracle.jdbc.pool.OracleDataSource 
(which is used by the Universal Connection Pool)

Within main(String args[]) and a try{...}catch(SQLException e){...}
I do:

   OracleDataSource ods = null;
   ods = new OracleDataSource();
   ods.setURL(args[0]); // this gets passed: jdbc:oracle:thin:/@mydbname

   ods.setConnectionCachingEnabled(true);

   Properties cacheProps = new Properties();
   cacheProps.setProperty("InitialLimit", "1");
   ods.setConnectionCacheProperties(cacheProps);

   Connection conn =  ods.getConnection();

If I comment out the caching altogether, the db-connection succeeds
(which I take as a proof that wallet and tnsnames.ora are correctly
set up.)

If I enable caching, but comment out setting of InitialLimit, then I get
an SQLException: "User credentials doesn't match the existing ones"
which I don't quite understand and also didn't find anything useful 
on google for.

If I leave the code as shown, I get a NullPointerException:
        at oracle.jdbc.pool.OracleImplicitConnectionCache.defaultUserPrePopulateCache(OracleImplicitConnectionCache.java:252)
        at oracle.jdbc.pool.OracleImplicitConnectionCache.<init>(OracleImplicitConnectionCache.java:206)
        at oracle.jdbc.pool.OracleConnectionCacheManager.createCache(OracleConnectionCacheManager.java:453)
        at oracle.jdbc.pool.OracleConnectionCacheManager.createCache(OracleConnectionCacheManager.java:272)
        at oracle.jdbc.pool.OracleDataSource.cacheInitialize(OracleDataSource.java:737)
        at oracle.jdbc.pool.OracleDataSource.getConnection(OracleDataSource.java:685)
        at oracle.jdbc.pool.OracleDataSource.getConnection(OracleDataSource.java:308)
        at oracle.jdbc.pool.OracleDataSource.getConnection(OracleDataSource.java:249)
        at DirectTest.main(DirectTest.java:53)

Conclusion: a non-cached ods.getConnection() *does* use the wallet just fine, 
but if it creates a connection just for filling the cache, then it doesn't use
the Wallet for it.


My production code doesn't use OracleDataSource, but
oracle.ucp.jdbc.PoolDataSourceFactory . This test tool was just an
attempt to pinpoint the problem more closely, since PoolDataSource
doesn't provide any information beyond telling me that the pool
"just wasn't filled."

[toc] | [prev] | [next] | [standalone]

#38644

Andreas Leitgeb <avl@logic.at> wrote:
> I've got a testcase using oracle.jdbc.pool.OracleDataSource 
> (which is used by the Universal Connection Pool)

Not sure if anyone remembers it, but the problem was finally
reported to Oracle support, and eventually(*) we got a patch
number back, and after downloading and applying the patch the
problem was solved.

*: the process took much longer than necessary, because they
apparently didn't read the gobs of information they explicitly
asked for...

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web