From: | Peter Mount <petermount(at)it(dot)maidstone(dot)gov(dot)uk> |
---|---|
To: | "'Sverre H(dot) Huseby'" <shh(at)thathost(dot)com>, pgsql-interfaces(at)postgresql(dot)org |
Subject: | RE: UNFINISHED code for more scalable JDBC driver av ailable |
Date: | 2000-07-05 13:37:59 |
Message-ID: | 1B3D5E532D18D311861A00600865478CF1B01B@exchange1.nt.maidstone.gov.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-interfaces |
I'll take a look. I was thinking of doing like this on the jdbc 2 driver.
Even though you say it's "Unfinished" it may save me a lot of time ;-)
As for being another one, there is another one (openlink) that I know of,
but their's is not free, and not type 4 (ie pure java).
Peter
--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council
-----Original Message-----
From: Sverre H. Huseby [mailto:shh(at)thathost(dot)com]
Sent: Sunday, July 02, 2000 5:27 PM
To: pgsql-interfaces(at)postgresql(dot)org
Subject: [INTERFACES] UNFINISHED code for more scalable JDBC driver
available
[I'm posting this here as someone may find it usefull]
The README.txt -file:
WARNING! This is unfinished code! It may never be finished by the
original author, as time currently does not permit this kind
of hacking. If this didn't scare you off, please read on.
Another PostgreSQL JDBC Driver?
===============================
This is a _highly_ unfinished JDBC1 driver for the PostgreSQL RDBMS.
I stopped developing it when it reached a point where I could use it
in several small projects that do not depend on advanced JDBC
features.
Why another JDBC driver when PostgreSQL already has a fully usable
driver? The main reason is that the way the original driver handles
result sets does not scale very well: The entire result from a query
is stored in a Vector before the caller gets to receive the first
row. My driver uses a cursor for reading a caller settable number of
rows before returning the first row to the user. This way you will
not run out of memory when processing tens of thousands of rows.
Another reason for writing the driver, is that I tend to like playing
with what most people consider low level stuff (not that a driver
written in Java is _that_ low level). I must, however, admit that
planning is not as fun as programming, so I've discovered a couple of
things that I would have done differently if I was to write this
driver a second time. Things that would speed things up even more (my
driver seems to be a bit faster than the original driver).
Note: As mentioned above, the original PostreSQL JDBC driver
prefetches the entire result from a query before returning anything to
the caller. My driver does not. The implication is that the new
driver will not be able to start executing a new query on a connection
before an old query has ended (all results returned, or explicite
close). You will probably see exceptions you haven't seen before, but
this is according to the spec (I even mailed one of the spec authors
on this subject).
If you want to use this code, you're COMPLETELY ON YOUR OWN! Be
prepared to read some poorly documented source code. Queries and
result set traversals seem to work though (I've been running three
different servlets for several months without problems), so you _may_
find the code useful.
If you want to continue development, just go for it. I would be happy
to hear from you. I have very little spare time these days (wife,
kids, two jobs), so I will probably not be able to participate
actively.
Thanks for reading, and good luck with whatever you do next (including
something completely different).
Driver home: http://shh.thathost.com/pub-java/
Sverre.
--
<URL:mailto:shh(at)thathost(dot)com>
<URL:http://shh.thathost.com/> Echelon bait: semtex, bin
Laden,
plutonium, North Korea, nuclear
bomb
From | Date | Subject | |
---|---|---|---|
Next Message | george stewart | 2000-07-05 14:01:01 | column metadata for numeric from jdbc driver |
Previous Message | Peter Mount | 2000-07-05 08:05:15 | RE: Default mode for transaction in postgreSQL and J DBC |