Tuesday Jun 05, 2012

Quick Fix for GlassFish/MySQL NoPasswordCredential Found

Just the other day, I stood up a GlassFish 3.1.2 server in preparation for a new web app we've developed. Since we're using MySQL as the back-end database, I configured it for MySQL (driver) and created the requisite JDBC resource and supporting connection pool. Pinging the finished pool returned a success, and all was well.

Until we fired up the app, that is -- in this case, after a weekend. Funny how things seem to break when you leave them alone for a couple of days. :-) Strangely, the error indicated "No PasswordCredential found". Time to re-check that pool.

All the usual properties and values were there (URL, driverClass, serverName, databaseName, portNumber, user, password) and were populated correctly. Yes, the password field, too. And it had pinged successfully. So why the problem?

A bit of searching online produced enough relevant material to offer promise. I didn't take notes as I was investigating the cause (note to self), but here were the general steps I took to resolve the issue:

First, per some guidance I had found, I tried resetting the password value to nothing (using () for a value). Of course, this didn't fix anything; the database account requires a password. And when I tried to put the value back, GlassFish politely refused. Hmm.

I'd seen that some folks created a new pool to replace the "broken" one, and while that did work for them, it seemed to simply side-step the issue. So I deleted the password property - which GlassFish allowed me to do - and restarted the domain. Once I was back in, I re-added the password property and its value, saved it, and pinged...success! But now to the app for the litmus test.

The web app worked, and everything and everyone was now happy. Not bad for a Monday.  :-D

Hope this helps,
Mark

Sunday Apr 29, 2012

Performance Test: DriverManager vs. DataSource

I was troubleshooting some well-traveled Java code the other day and hit an intriguing set of circumstances. The original developer(s) of this code -- a web application using JSP/servlets -- had written a data wrapper construct using DriverManager. After several upgrades of JDK and JVM, some minor cracks were starting to show.

We tried doing a direct transplant of DataSource-based code into the wrapper mechanism, effectively a one-for-one swap of the minimum number of lines of code without any real refactoring. Yes, I know...not a good idea for the long-term. But one has to start somewhere.  :-)

Interestingly, performance tanked. When things like that happen, it's time to get curious and dig deeper.

Why DataSource?

The DataSource approach to data connectivity brings numerous benefits with it (connection pooling, distributed transactions, etc.), but does it also carry a hefty performance penalty? I had never heard that it did. Either way, it's always good to do a little first-person testing to verify/refute findings. So off we go!

Testing Methodology

I put together a pretty simple test and ran it several times to factor out normal variations in environmental conditions. Using NetBeans, I created a plain-vanilla web application, sans frameworks. Next, I asked NetBeans to generate JPA entities from some tables in our database, and then an EJB (see this recent article for a refresher on connecting a basic EJB to underlying data via a DataSource) to provide the DataSource-based baseline. I then created an EJB that used DriverManager to build a connection and SQL statements for comparison.

Oh, and one last necessity: I created a couple methods to capture start/stop times using System.currentTimeMillis() for a timekeeper. That covered all the essentials.

And the Winner Is...

Well, there really wasn't a runaway winner strictly from a performance perspective. Results varied from run to run, but these two horses were neck and neck, often trading the lead by only a few milliseconds in consecutive runs...which is great news, considering that DataSource offers so much more and yet manages to retain the expected level of performance.

The bad news? Well, it's clear I have a lot of rework to do on this old code.

Sigh.  :-)

For more fun with Java, click here to follow Mark on Twitter.

About

The Java Jungle addresses topics from mobile to enterprise Java, tech news to techniques, and anything even remotely related. The goal is to help us all do our work better with Java, however we use it.

Your Java Jungle guide is Mark Heckler, an Oracle Java/Middleware/Core Engineer with development experience in numerous environments. Mark's current work pursuits and passions all revolve around Java and leave little time to blog or tweet - but somehow, he finds time to do both anyway.

Mark lives with his very understanding wife, three kids, and dog in the St. Louis, MO area.



Stay Connected

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today