> Are there alternatives to jTDS, when accessing
> MS SQL Databases?
The obvious one is to use the JDBC driver provided by
Microsoft.
Arne
Jan Burse - 13 May 2008 01:03 GMT
Arne Vajhøj schrieb:
>> Are there alternatives to jTDS, when accessing
>> MS SQL Databases?
>
> The obvious one is to use the JDBC driver provided by
> Microsoft.
There were some problems with the Microsoft driver
when I looked into it 2006. Some problems with opening
multiple cursors over the same database connection
session...
Are these solved now?
Arne Vajhøj - 13 May 2008 01:54 GMT
> Arne Vajhøj schrieb:
>>> Are there alternatives to jTDS, when accessing
[quoted text clipped - 9 lines]
>
> Are these solved now?
I don't know because I don't know that specific problem.
But Microsoft actually updates the drivers frequently, so
it could be fixed.
SQLServer 2000 driver is at SP3 dated July 2004.
SQLServer 2005 driver is at version 1.2 dated October 2007.
SQLServer 2008 driver is promised soon.
Arne
> Dear All
>
> I was just looking up the source code of the jTDS driver.
> It seems that it is trashing the heap with java.lang
> wrapper classes, even when one is using only primitive
> types in his application.
Why do you call this "trashing the heap"?
> For example, when I am doing, whereas the column
> is integer:
[quoted text clipped - 11 lines]
> During the above call a Long object will be created, as
> can be seen from the convert implementation:
Yes, so?
> A solution would be to do the following
> call on the result set:
A solution to what? You have yet to present a problem.
> (long)set.getInt(1);
>
> But what if I want to make the code, lets say column
> size independent, and want to use a getLong() call
> only.
Then just use that call.
> Does this trashing happen in every JDBC driver?
This is not "trashing". Why do you call it that?
It is likely that all JDBC drivers convert SQL types to reference types in
Java. Every column is required to work with ResultSet#getObject() and to
handle the possibility of a (SQL) NULL value in the column. NULL is not in
the domain of primitive values, so the driver really must use a reference type.
> Are there alternatives to jTDS, when accessing
> MS SQL Databases?
jTDS is a stable, performant, high-quality product. I doubt you'll find better.
What is the problem? You never stated a problem.

Signature
Lew
Jan Burse - 13 May 2008 01:03 GMT
Lew schrieb:
> What is the problem? You never stated a problem.
Thrashing = unnecessarily filling the heap with objects,
and thus using up processor time, because of heap alloc
calls and gc calls.
Could for example in the case of getLong() be prevented
by a more elaborate implementation of Support.convert.
But anyway no pun intended on jTDS, I am using it all day.
Best Regards
Lew - 13 May 2008 05:14 GMT
> Lew schrieb:
>
[quoted text clipped - 3 lines]
> and thus using up processor time, because of heap alloc
> calls and gc calls.
You make it sound so dire. Allocating these objects takes next to no time, GC
will be fast since they'll all be unreachable, and you don't have to worry
about it. Not only that, but Hotspot will probably optimize away the object
calls in favor of primitives anyway, possibly enregistered.
All this fuss over a little heap allocation. Tsk, tsk.

Signature
Lew
Jan Burse - 13 May 2008 19:25 GMT
Lew schrieb:
> You make it sound so dire. Allocating these objects takes next to no
> time, GC will be fast since they'll all be unreachable, and you don't
> have to worry about it. Not only that, but Hotspot will probably
> optimize away the object calls in favor of primitives anyway, possibly
> enregistered.
The hotspot is not infinitely smart, and alloc/gc is not negliable.
Try the following two codes:
Variant 1:
Color red=new Color(0xff0000);
g.setColor(red);
for (int x=0; x<1000; x++) {
for (int y=0; y<1000; y++) {
g.drawRect(x,y,1,1);
}
}
Variant 2:
for (int x=0; x<1000; x++) {
for (int y=0; y<1000; y++) {
Color red=new Color(0xff0000);
g.setColor(red);
g.drawRect(x,y,1,1);
}
}
There is a huge difference between the two
in performance.
Similarly one can waste performance in JDBC
drivers or what ever...
Best Regards
Lew - 14 May 2008 00:28 GMT
> Lew schrieb:
>> You make it sound so dire. Allocating these objects takes next to no
[quoted text clipped - 28 lines]
> There is a huge difference between the two
> in performance.
Huge relative to what? The JDBC calls through to the database?
I don't think so.
Furthermore, you give no evidence that the example you show is bound by
allocation or GC performance, rather than the speed of graphics calls. What
does g.setColor() do?
By pulling the setColor() call inside the loop, you make it unclear whether
it's that or the 'new' call that is causing your overhead.
You don't show how much difference allocation makes, nor GC, nor how it fits
into the context of *database* calls, which are not CPU bound.
Again I say, you are performing premature optimization, absent any evidence
that the allocation and GC are causing you any significant time overhead
relative to your application. I suggest that you *measure* the impact of the
allocations and GCs, which will be very fast.
Are you really setting the color a million times in a row, vs. setting it once
for a million operations? Do you have a million calls into the database in a
short time, thus motivating your optimization concerns?
Somehow I don't think so.

Signature
Lew
Jan Burse - 14 May 2008 22:00 GMT
Lew schrieb:
> Do you have a million calls into the
> database in a short time, thus motivating
> your optimization concerns?
I have approx. 1'000 DB calls per
item. And I have ca.
6'000 items.
The first version of the batch run
around 8 hours. Now I am down to
1 1/2 hours.
I am now using a custom memory cache
between the DB and the application.
Bye
Lew - 15 May 2008 04:29 GMT
> Lew schrieb:
>> Do you have a million calls into the database in a short time, thus
[quoted text clipped - 4 lines]
> item. And I have ca.
> 6'000 items.
Interesting notation. Where does it come from?
> The first version of the batch run
> around 8 hours. Now I am down to
> 1 1/2 hours.
>
> I am now using a custom memory cache
> between the DB and the application.
Clearly you were I/O bound before, and memory allocation and GC were not the
issue.
QED.

Signature
Lew