Loading ...
Sorry, an error occurred while loading the content.
 

Re: [Firebird-Java] Another code that worked in 1.5.5 and no more in 2.0.1 ... closing a ResultSet

Expand Messages
  • Edilmar
    ... To better understand: if I have a system with 1-million lines of code, with so many Statements/Prepared/Call/etc and AutoCommit=true (default value), do I
    Message 1 of 5 , Apr 3 8:21 AM
      Roman Rokytskyy escreveu:
      > > When the line 203 runs, opening the ResultSet rsCons2, the ResultSet
      > > rsCons is closed, with no exceptions...
      >
      > You do this in auto-commit mode and this behavior is fully JDBC compliant.
      > It was fixed in Jaybird 2.0 and described in release notes (page 4, third
      > paragraph). If you want your old functionality back, switch the auto-commit
      > mode off.
      >
      > Roman
      >
      >

      To better understand: if I have a system with 1-million lines of code,
      with so many Statements/Prepared/Call/etc and AutoCommit=true (default
      value), do I have to change all the code putting AutoCommit=false?

      I think this is a crazy method for SUN to change the way things work in
      systems. Imagine each new JDBC spec if we have to change our
      "error-proof" code, that worked fine in older versions of JDBC.
    • Roman Rokytskyy
      ... More or less... though I doubt that you can have a stable system that works in auto-commit mode with more than 1,000 lines of code, but that is my personal
      Message 2 of 5 , Apr 3 8:46 AM
        > To better understand: if I have a system with 1-million lines of code,
        > with so many Statements/Prepared/Call/etc and AutoCommit=true (default
        > value), do I have to change all the code putting AutoCommit=false?

        More or less... though I doubt that you can have a stable system that works
        in auto-commit mode with more than 1,000 lines of code, but that is my
        personal opinion :-)

        > I think this is a crazy method for SUN to change the way things work in
        > systems.

        Well... the issue is that we allowed too much in our previous version of
        JDBC driver. The behaviour of the driver in auto-commit mode was not
        specified by Sun detailed enough to allow same interpretation until JDBC
        3.0.

        Firebird does not support open cursors accross commits (there is a
        workaround with COMMIT RETAIN, but it brings more problems than solves).
        Since auto-commit means that each statement has to be executed in a separate
        transaction, we had to provide this functionality in the driver. We (Jaybird
        team) felt that supporting only one open statement in auto-commit mode is
        too restrictive and JDBC specification (and support forums) were of little
        help, it was decided to cache the complete result set locally and commit
        transaction right after query execution.

        This decision had one very big drawback - the memory usage. So, when JDBC
        3.0 has specified the exact behaviour in auto-commit case, we have decided
        to follow it, as we no longer needed to cache the result set locally, since
        the lifetime of the request is now clearly defined and this case is fully
        supported by Firebird.

        You can get the old functionality by constructing scrollable and holdable
        result set:

        Statement stmt = conn.createStatement(
        ResultSet.TYPE_SROLL_INSENSITIVE,
        ResultSet.CONCUR_READONLY,
        ResultSet.HOLD_CURSORS_OVER_COMMIT);
        ResultSet rs = stmt.executeQuery(....);
        while(rs.next()) {
        // do something else
        }

        but this requires changing the application.

        So, as it was already posted on this list many times, in Jaybird 2.1 we will
        include connection propery that will allow to specify the type, concurrency
        and holdability of the default result set (the one you create by
        Connection.createStatement() method).

        Why didn't we include this in 2.0? The answer is simple - nobody complained
        loudly, and those that found their system to be incompatible with JDBC 3.0
        decided to rather fix the system to be specification compatible than to
        require a workaround. However, already after 2.0 release it was discovered
        that OpenOffice 2.0 has problems too, and since we want OpenOffice beginners
        to use Firebird, we will add such workaround.

        > Imagine each new JDBC spec if we have to change our "error-proof" code,
        > that worked fine in older versions of JDBC.

        That is not 100% true. Previous case was "implementation specific", now it
        is standardized. This is always so when one relies on
        implementation-specific artifacts.

        Roman
      • William L. Thomson Jr.
        ... Will this be a temp or permanent solution? Seems like it should be a temp one till OO addresses the known issue. Does not seem like functionality should
        Message 3 of 5 , Apr 3 10:17 AM
          On Mon, 2006-04-03 at 17:46 +0200, Roman Rokytskyy wrote:
          >
          > So, as it was already posted on this list many times, in Jaybird 2.1 we will
          > include connection propery that will allow to specify the type, concurrency
          > and holdability of the default result set (the one you create by
          > Connection.createStatement() method).

          Will this be a temp or permanent solution? Seems like it should be a
          temp one till OO addresses the known issue. Does not seem like
          functionality should exist that goes against the standard specification.

          > Why didn't we include this in 2.0? The answer is simple - nobody complained
          > loudly, and those that found their system to be incompatible with JDBC 3.0
          > decided to rather fix the system to be specification compatible than to
          > require a workaround. However, already after 2.0 release it was discovered
          > that OpenOffice 2.0 has problems too, and since we want OpenOffice beginners
          > to use Firebird, we will add such workaround.

          The workaroud will be need to fix the implementation specific issues, in
          the current OO. If the OO developers resolve that. Then will there be
          any need or use to the workaround?

          Other than for people migrating from older versions of JayBird. In which
          case their apps do not conform to the standard. Since they are relying
          on using a non standard "implementation" feature. Seems like in those
          cases best to break the app, so it can be modified to conform with
          stadards.

          --
          Sincerely,
          William L. Thomson Jr.
          Obsidian-Studios, Inc.
          http://www.obsidian-studios.com
        Your message has been successfully submitted and would be delivered to recipients shortly.