Re: JDBC and JVM question

From: Dave Glasser (dglasser_at_pobox.com)
Date: 11/01/03 

Date: Sat, 01 Nov 2003 17:00:52 -0500

Joe Weinstein <joeNOSPAM@bea.com> wrote on Sat, 01 Nov 2003 13:30:46
-0800 in comp.lang.java.databases:

>
>
>Joe Weinstein wrote:
>
>> I just checked the very latest 5.5 EBF driver. It still only registers
>> itself on instantiation:
>>
>> public class SybDriver
>> implements com.sybase.jdbcx.SybDriver
>> {
>>
>> public SybDriver()
>> {
>> _version = 5;
>> registerWithDriverManager();
>> }
>>
>> I also checked to see if this was redundant, and no, there is
>> no static initializer block. Furthermore, the registerWithDriverManager
>> routine goes through a silly fire drill of looking for any other driver
>> instance so as to deregister it and register this new instance. Thus
>> every time some one runs the newInstance() call, there is a needless
>> change of regime in DriverManager from one perfectly good driver instance
>> to an identical (the class is loaded only once) new one...
>> "Chaqu'un sans gout"...
>> Joe Weinstein at BEA
>>
>> PS:
>> You could test it by a simple program that just does
>> Class.forName() (without calling for a new instance), and then call the
>> DriverManager call to list the loaded drivers.
>
>I take it back partially! I couldn't simply doubt you so I ran the test
>I suggested, and found that the 5.2 and 5.5 driver does have a static block,
>that does instantiate a Driver instance. It doesn't explicitly register
>the instance, which is why I missed finding it the first time. Instead,
>it relies on the code I showed you above in the constructor, to do the
>registering (which as I said, occurs every time newInstance() *or*
>Class.forName() is called. It would be much more efficient of they just
>had the static block be:
>
> static
> {
> DriverManager.registerDriver(new SybDriver());
> }
>
>And the constructor be:
> public SybDriver()
> {
> _version = 5;
> }
>
>There would be no need for the registerWithDriverManager() routine.

I'm not sure, because I haven't used Sybase since mid-2001, but I
think the classname we were passing to Class.forName was
com.sybase.jdbc2.jdbc.SybDriver, not com.sybase.jdbcx.SybDriver. Could
that account for the difference? I do remember clearly that
Class.forName worked, though, because some of my very first JDBC (and
Java) code was written against a Sybase database, and that's all I
knew how to do at the time.

Relevant Pages

  • Re: JDBC and JVM question
    ... > public SybDriver() ... > change of regime in DriverManager from one perfectly good driver instance ... > Joe Weinstein at BEA ... There would be no need for the registerWithDriverManager() routine. ...
    (comp.lang.java.databases)
  • Re: Java vs SQL Server float datatype limits
    ... However Java double has a much wider range: ... Joe Weinstein at BEA Systems ... So I would have imagined that an SQL Server driver either handle the ... The JDBC specification says something about the driver being expected to coerce the Java data type into the correct data type for the server the driver is representing. ...
    (microsoft.public.sqlserver.jdbcdriver)
  • Re: ResultSet.updateString against DB2 giving "Column not updatable"
    ... I just based my conclusion on the obvious driver response ... program that makes a JDBC connection, creates a table, inserts ... Check the driver documents about this. ... Joe Weinstein at BEA Systems ...
    (comp.lang.java.databases)
  • Re: executeBatch()
    ... Joe Weinstein wrote: ... >> Is this a limitation of the database or of the driver? ... > all together in one network packet, ... If it doesn't, it's because the driver ...
    (microsoft.public.sqlserver.jdbcdriver)