Re: Infinity and beyond

From: "Donald Fraser" <postgres(at)kiwi-fraser(dot)net>
To: "[JDBC]" <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: Infinity and beyond
Date: 2005-05-06 09:33:57
Message-ID: 011101c5521e$ba952440$0264a8c0@demolish1
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc


> Donald Fraser wrote:
>
> > As for being familiar with the 8.0.x driver - I'm always one driver version
> > behind as I have a number of more significant modifications to the driver
> > that require patching and unless there are major enhancements I usually
> > leave it a while, time permitting and all that... Hence I am only familiar
> > with the 7.4 and earlier versions of the driver. I will endeavour to take a
> > look at what changes have been made sometime soon.
>
> Are any of your local changes things that you'd like to see rolled into
> the main driver?
>

I'd like all the changes in the main driver - but them I'm not driving the project so it'll be up to whoever's in charge...
First I'd need to check on the latest driver and see what new and what's not.
Second some of the changes were made due to lack of features that date back to the 7.2 version of the driver and now I could probably get around some of these problems as of the 7.4 version or more correctly the PostgreSQL version 3 communication protocol.
What's probably easier, is if I outline a list of features that I've added and I'll let you decide whether they're worth looking at, in case they aren't already implemented in the latest driver. I'll give a brief explanation as to why I found it necessary to make these changes so that in the case I missed something that was already available via a different approach you can point out my stupidity....;-)
In any case please don't think that I'm complaining in any way about the quality of the drivers - I'm grateful that they exist in the first place!

1) Exceptions: are a big part of programming especially when dealing with mediums outside the control of your software. What was missing in the early version of the driver was the ability to detect a loss of connection. Whilst the PGSQLException class clearly reported that a connection was lost, it was difficult for client software to determine this, especially for the case of unattended automatic recovery. The reason it was difficult was that the driver was maintaining compatibility across all three versions of the JDBC API and therefore not utilising enhancements available in later JVMs. For example being able to set the cause of an exception was introduced in the Java 1.4 VM, yet this feature was not utilised at all in the JDBC 3.0 API of the driver simply because it was difficult to maintain all three APIs when this feature wasn't available in earlier JVMs. I'm sure that there were other solutions to capturing connection losses, but setting the cause of the exception had other gains that I also found necessary. For example I didn't like the full stack trace being added to the exception message on IO exceptions. End users want simple messages - not a technical report useful only to programmers. For this reason I also cleaned up the exception class to give cleaner messages and whilst I was at it I added a driver option to allow formatting of the exception messages with or without HTML.
In summary:
i) Added exception cause to PGSQLException
ii) Cleaner exception messages.
iii) Driver option to format exception messages in HTML.

Side effects: Driver is broken in terms of compatibility across all three of the JDBC APIs, hence these changes only apply to the JDBC 3.0 API.

2) Notifications: I didn't like having to poll the driver or the database for PostgreSQL asynchronous NOTIFY messages. I therefore modified the driver to use java listeners to notify clients automatically when a NOTIFY was received - no polling required. The initial modification to the driver was very simple and used a worker thread to effectively poll the PGStream object for incoming messages. Unfortunately this implementation didn't work on ssl sockets due to implementation incompatibilities produced by SUN between an ssl socket and a non-ssl socket (I claim it to be an implementation bug by SUN but they disputed it). I therefore had to go for the more efficient approach of completely blocking on the input stream object until data is received. Because of this approach, sending and receiving data requires a two stage object synchronization mechanism before you can start sending or receiving data, where as before you only needed to synchronize on one object. This is all technical stuff hidden from the client.

3) Encoding: At first I didn't like the fact that the driver would through an exception when translating characters into Unicode that clearly weren't Unicode. The main problem is that I don't use Unicode. Just because we have a nice language that supports Unicode doesn't mean that we should be forced into using Unicode. As of version 7.3, the driver forced the encoding to be Unicode which meant that my java clients could easily save Unicode characters into the database which was a big no no as not all clients of the database have Unicode - hence the reverse problem in translating characters into Unicode on the java platform. To overcome this problem I simply added a couple of methods to the driver connection to set and get the encoding.
A very simple modification.

4) Multiple result sets: Don't get excited - I didn't implement multiple result sets... The problem that arose here was that our database is built heavily around the use of views. Views (and tables for that matter) can have one or more rules which each return in their own right a result set. Therefore executing update or insert statements on a view with multiple rules will return multiple result sets. None of the drivers have ever supported this, as soon a second result set was detected the driver would through an exception informing you that it didn't support multiple result sets. What I had to do here was silently ignore previous results sets.
Again a very simple modification.

5) CipherSuite: Added the ability to retrieve the cipher suite used on ssl connections.
Yet again another simple modification.

All of these modification have been in production for well over a year now and most have been in pre-production use for nearly three years.
As you can see some of these modification are debatable as to their necessity, therefore if you think any of them are useful let me know and I'll work out a means of patching them to the latest driver.

Regards
Donald Fraser

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Oliver Jowett 2005-05-06 11:22:19 Re: Infinity and beyond
Previous Message DavidB 2005-05-05 23:46:46 Re: Postgres v8 jdbc connect fails while v7.4 connection