db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Satheesh Bandaram <sathe...@Sourcery.Org>
Subject Re: default holdability
Date Wed, 22 Feb 2006 19:15:51 GMT
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
I don't think changing default holdability is a good idea... like Dan
and Dag mentioned. Why does Derby have to change default holdability
because SUR and XA can't support it? Also Derby doesn't have SQL
cursors, only JDBC cursors, right?<br>
<br>
Even if default is changed, SUR and XA will still not be able to
support holdability. Changing default once caused too many issues, but
atleast then automatic upgrade wasn't support for applications.<br>
<br>
Satheesh<br>
<br>
Bernt M. Johnsen wrote:<br>
<blockquote cite="mid20060222181616.GC12421@localhost.localdomain"
 type="cite">
  <pre wrap="">Hi all,

Allthough I agree that backwards compatability is important, I find
the current default unfortunate for several reasons:
1) As Anreas points out: The architecture seems to be designed for
   non-holdable cursors (in agreement with the old Cloudscape
   default). 
2) Cursors in the SQL standard defaults to non-holdable
3) It does not fit very well with global transactions

And I am not convinced that very many exsisting apps depend on
resultsets being holdable without being explicit in the JDBC calls.


  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <blockquote type="cite">
                  <blockquote type="cite">
                    <blockquote type="cite">
                      <blockquote type="cite">
                        <blockquote type="cite">
                          <pre wrap="">Dag H. Wanvik wrote (2006-02-22 18:09:04):
                          </pre>
                        </blockquote>
                      </blockquote>
                    </blockquote>
                  </blockquote>
                </blockquote>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">Hi,

Daniel John Debrunner <a class="moz-txt-link-rfc2396E" href="mailto:djd@apache.org">&lt;djd@apache.org&gt;</a>
writes:

    </pre>
    <blockquote type="cite">
      <pre wrap="">The JDBC 3.0 spec is silent on this, sections 14.1.1 and 14.1.2 describe
what can be done when a ResultSet type or concurrency is not supported.
However in 14.1.3 there is no comment about what can be done when a
requested holdability is not supported. Also ResultSet does not have a
getHoldability method to allow the application to determine if its
request was honoured or not.

I just can't see the value in changing the default behaviour and
affecting existing applications because holdability is not supported in
two cases.
      </pre>
    </blockquote>
    <pre wrap="">I agree with Dan on this one. Rather than risk breaking existing apps,
for SUR, we should just document this for now; hopefully we can find a
solution for holdable SUR also, along the lines Mike outlined (by
invalidating open result sets when inline compress happens), so the
restriction can be lifted.

Thanks,
Dag


    </pre>
    <blockquote type="cite">
      <pre wrap="">I seem to remember that most users assumed Cloudscape in the past
supported holdable results sets and expected it to be the default. They
 were suprised when it didn't.

Dan.

      </pre>
    </blockquote>
    <pre wrap="">-- 
Dag H. Wanvik
Sun Microsystems, Database Technology Group (DBTG)
Haakon VII gt. 7b, N-7485 Trondheim, Norway
Tel: x43496/+47 73842196, Fax:  +47 73842101
    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
</blockquote>
</body>
</html>


Mime
View raw message