Re: MS SQL Server JDBC connections

Problem solved - I dumped the MS SQL JDBC Driver in favour of
http://jtds.sourceforge.net/ 

Performance is now similar on PC, iSeries, and Linux, (as it ought to be
with a networked bound application), and faster than it was before (even on
the PC).

The moral - never trust Microsoft to do anything with Java in the
title...(vbg)

-----Original Message-----
From: wdsci-l-bounces@xxxxxxxxxxxx [mailto:wdsci-l-bounces@xxxxxxxxxxxx] On
Behalf Of Price, Chris
Sent: 28 February 2006 13:18
To: Websphere Development Studio Client for iSeries
Subject: Re: [WDSCI-L] MS SQL Server JDBC connections

Just to tidy up this discussion, I've now tried running my code on a linux
box, and it's just as slow as on the iSeries. So whatever the problem is,
it's nothing to do with the iSeries.

This is pure speculation, but it may be that the MS JDBC driver doesn't work
very well when used on non-Windows platforms...

Thanks to those who tried to help.
Regards,
Chris.

-----Original Message-----
From: wdsci-l-bounces@xxxxxxxxxxxx [mailto:wdsci-l-bounces@xxxxxxxxxxxx] On
Behalf Of Price, Chris
Sent: 23 February 2006 08:42
To: Websphere Development Studio Client for iSeries
Subject: Re: [WDSCI-L] MS SQL Server JDBC connections

Once the connection is open the sql itself performs fine - it's just getting
the connection object that seems to take some time.

Unfortunately I can't ping or ftp to the server - it's in the DMZ behind a
firewall, and only specific ports are open (such as 1433 for the jdbc
driver).

Thanks for everybody's help. Since no-one leapt in and said "oh yeah, that
happened to me" I'm inclined to assume that it's just a feature of our
network here.

-----Original Message-----
From: wdsci-l-bounces@xxxxxxxxxxxx [mailto:wdsci-l-bounces@xxxxxxxxxxxx] On
Behalf Of DeLong, Eric
Sent: 22 February 2006 23:15
To: 'Websphere Development Studio Client for iSeries'
Subject: Re: [WDSCI-L] MS SQL Server JDBC connections

That doesn't seem likely, since his datasource is MS Sql Server....  No
direct access to MS sequel server from iSeries.

I don't suppose a simple ping might yield any significant answers, but I've
seen problems where iSeries is 100/Full, plugged into a router setup for
100/auto, where thruput sags...

Can you ftp something from the iSeries to the MS box, to verify the
connection speed?

You should be able to see the JDBC connection socket listen in NETSTAT *CNN.
There's various performance metrics listed there that might help pin down
the problem...

hth,

Eric DeLong
Sally Beauty Company
MIS-Project Manager (BSG)
940-297-2863 or ext. 1863



-----Original Message-----
From: wdsci-l-bounces@xxxxxxxxxxxx
[mailto:wdsci-l-bounces@xxxxxxxxxxxx]On Behalf Of Elvis Budimlic
Sent: Wednesday, February 22, 2006 4:41 PM
To: 'Websphere Development Studio Client for iSeries'
Subject: Re: [WDSCI-L] MS SQL Server JDBC connections


Chris, 
What type of work your 'extract' process does?  
If it's SQL type of work, did you try running those queries outside java
(i.e. STRSQL or RUNSQLSTM)?
I'm thinking that could help you eliminate database as culprit so you know
you're correct to focus on enhancing Java performance.

Elvis

-----Original Message-----
Subject: Re: [WDSCI-L] MS SQL Server JDBC connections

Thanks for the reply guys, but the problem is occurring after the JVM has
started - my timings are generated in the main method being executed. Before
creating the SQL Server connection, which is what seems to hang, an iSeries
JDBC connection is already created, which is much quicker. 

I think the problems are either:
- something to do with the SQL Server JDBC driver, (perhaps a property needs
setting somewhere).
- are network related (but since both the iSeries and development PC's are
on the Lan and the SQL server is in a DMZ, I would have though that the
connection speeds would be similar.)
- resource related - it just happens to be at this point the jvm runs out of
memory and starts asking for more? (does anyone have any tuning pointers?)

Once the connection created the actual data transfers take roughly the same
amount of time.

Regards,
Chris.