Tomcat and jTDS - not that stable...

[Rico]

Hello ppl.

I've been trying to use jTDS instead of Sun's JDBC-ODBC bridge in our web
application.
I'm running into a couple of issues:

(i) seconds truncated when I getString( ) a column of type datetime,
whereas this doesn't happen with Sun's bridge.

(ii) I get NullPointerException on some data access but the former error
stops when I merely revert the driver and URL back to Sun's bridge

I am wondering, does Tomcat require any particular settings for
'3rd-party' drivers such as jTDS, whereas things are simpler for Sun's
bridge because it is part of the J2SE ?

If so, which settings would those be?
All database accesses are made from plain Java code in WEB-INF\classes
not from JSP.

For another standalone application I've written all I needed was
- driver class
- connection url
- username and password for SQL authentication
And it all works fine so far.

But under Tomcat, after placing jTDS.jar in common\lib, sometimes I run
into 'connection timeout' and subsequently trying to retrieve the data
read into my collections barfs ArrayIndexOutOfBoundsException.

Rico.

 

[Rico]

To add on, some rather weird observations:

(ii) I was previously using 'localhost' in the database connection URL.
From comparing and double-checking the compilation dates, I am positive
that I have uploaded onto the server a class that uses the actual computer
name instead of 'localhost'. Despite restarting Tomcat several times and
clearing the 'work' directory, the system is thumbing its nose at me for
when I print out the URL it still says 'localhost'; whereas on my machine
the computer name is printed out as expected. Where is the catche ?

(i) Okay, not so weird - the bridge returns the datetime as a String to 3
decimal places; the substring end-index needs to be readjusted to cater
for 1 d.p by jTDS.

Rico.

 

[Rico]

To add on, some rather weird observations:

(ii) I was previously using 'localhost' in the database connection URL.
From comparing and double-checking the compilation dates, I am positive
that I have uploaded onto the server a class that uses the actual computer
name instead of 'localhost'. Despite restarting Tomcat several times and
clearing the 'work' directory, the system is thumbing its nose at me for
when I print out the URL it still says 'localhost'; whereas on my machine
the computer name is printed out as expected. Where is the catche ?

I hate to be responding to myself... but who cares when it's 3AM ?

Anyway, I've _deleted_ the class from WEB-INF/classes/misc ... and
restarted Tomcat.

The class stored the URL as a static final String... and yet Tomcat is
not complaining and happily simply still printing the URL as being the one
with localhost ... I must be missing something very obvious. :S

Rico.

 

[Rico]

I hate to be responding to myself... but who cares when it's 3AM ?

Anyway, I've _deleted_ the class from WEB-INF/classes/misc ... and
restarted Tomcat.

The class stored the URL as a static final String... and yet Tomcat is
not complaining and happily simply still printing the URL as being the one
with localhost ... I must be missing something very obvious. :S

That calls for a beer. I need a beer. Now.

Rico.

 

[Michiel Konstapel]

.... You don't refer to the URL from *another* class, do you? Compile time
constants are inlined at compile time. So, after compilation of

class A {
public static final String FOO = "foo";
}

class B {
void print() {
System.out.println(A.FOO);
}
}

B.class actually refers directly to "foo", there's no reference to A at
all.

That calls for a beer. I need a beer. Now.

Hehe
Cheers!
Michiel

 

[Rico]

... You don't refer to the URL from *another* class, do you? Compile time
constants are inlined at compile time. So, after compilation of

class A {
public static final String FOO = "foo";
}

class B {
void print() {
System.out.println(A.FOO);
}
}

B.class actually refers directly to "foo", there's no reference to A at
all.


Hehe
Cheers!

Cheers Michiel !
Thanks for the clue. That'd be why things worked after I had recompiled
the other classes that used the constant String.

Rico.

 

[Alin Sinpalean via JavaKB.com]

Rico,

If you encounter any problems with jTDS please submit them as bugs on SourceForge. We'll be more than glad to help you out.

Cheers,
Alin Sinpalean,
The jTDS Project.

 

[Rico]

Rico,

If you encounter any problems with jTDS please submit them as bugs on
SourceForge. We'll be more than glad to help you out.

Sure Alin. Thanks. I'll drop by some time.
I was facing a problem related to authentication previously.
My test system at home doesn't belong to a domain, SQL authentication
worked fine.
When I uploaded onto the production server, two things:

(i) I didn't upload the latest version of class A that imported static
fields from a separate class B that I had modified.
(ii) jTDS seems to have problems using SQL authentication when running in
Tomcat's "context" when a domain is present.

I solved (i) rather by chance before reading Michael's post to be clearer
on the situation. (ii) was more of a hunch, that I wish had come earlier,
to try and use domain=X and Windows authentication instead.
Not sure if the problem is with Tomcat, jTDS or the domain policy.
Thanks for the invite.

Rico.

 

[Alin Sinpalean via JavaKB.com]

Rico,

Being part of a Windows domain does not affect jTDS in any way. jTDS is a pure Java app and SQL authentication is totally independent of Windows domains. It might be the SQL Server configuration or something else.

Alin.