| From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
|---|---|
| To: | <jgagis(at)gmail(dot)com>, <pgsql-jdbc(at)postgresql(dot)org> |
| Subject: | Re: JDBC compressed stream |
| Date: | 2005-06-17 19:41:24 |
| Message-ID: | s2b2e118.040@gwmta.wicourts.gov |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-jdbc |
Since you specifically asked about other solutions than the JDBC driver
itself -- we use a middle tier which makes the JDBC requests. Clients
communicate with the middle tier through non-persistent queue-based JMS
(developed in-house) which can compress the message body. This works
well for us. If you run this middle tier on the database server, the
non-compressed data doesn't go "over the wire".
Alternatively, it would probably be less than a week's work to write a
JDBC driver which just forwarded the requests to a process which used
the postgres JDBC driver to hit the database. You would essentially
forward the requests and responses, with compression around those
portions which would benefit.
Just a couple quick ideas. Maybe it'll get you thinking in a direction
that will work even better for you.
-Kevin
>>> Javier <jgagis(at)gmail(dot)com> 06/17/05 11:26 AM >>>
. . .
Last question --> Anyone knows any other way to achieve compression
with other kind of solution???
. . .
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Oliver Jowett | 2005-06-17 21:28:51 | Re: JDBC compressed stream |
| Previous Message | John R Pierce | 2005-06-17 19:12:45 | Re: JDBC compressed stream |