db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik" <Dag.Wan...@Sun.COM>
Subject Re: Disussion surrounding holding off metadata changes until certain issues resolved
Date Tue, 25 Apr 2006 13:45:15 GMT

>>>>> "Kathey" == Kathey Marsden <kmarsdenderby@sbcglobal.net> wrote:

Kathey> This is a regression for JCC, but is not a problem for the original
Kathey> client release with the 10.2 server?  I don't understand why JCC and the
Kathey> original client release would behave differently in this
Kathey> regard. Could you explain?

I'll try :) With an old (10.1) client and a new (10.2) server, there
will be a problem for *both JCC and the Derby client* in that these
four metadata calls (changed for SUR) will show a wrong value, since
no down-negotiation happens for metadata calls:

	 deletesAreDetected(TYPE_SCROLL_INSENSITIVE) -> true
	 updatedAreDetected(TYPE_SCROLL_INSENSITIVE) -> true
	 ownDeletesAreVisible(TYPE_SCROLL_INSENSITIVE) -> true
	 ownUpdatesAreVisible(TYPE_SCROLL_INSENSITIVE) -> true

For the other method affected by SUR, supportsResultSetType, JCC
always returns false for all arguments, with both 10.1 and 10.2
servers, as far as I can see, and thus suffers no regression for this
call. The old Derby client has a bug (DERBY-965) which is only fixed
in 10.2, so the old Derby client would not show a regression with a
new server for supportsResultSetType.

Now, with new clients and new server, the Derby client will show the
SUR values for these calls, which is correct, including for the
soft/hard upgrade scenarios (after DERBY-1176). I don't know if there
will be a 10.2 version of JCC; if there will be, my point is that JCC
would continue to show wrong values for these four (detectability,
visibility) calls unless some special precaution was taken, since the
server don't differentiate between the clients on the metadata
calls. If the JCC client code for supportsResultSetType were corrected
to show the values returned by the server (in stead of always
returning false), it would have the same vulnerability: it would show
that SUR is supported, which I assume it would not be with JCC.

For the last case, new client and old server, for the Derby client the
four detectability and visibility calls are correct (return
false). The supportsResultSetType calls are wrong due to the server
side bugs of DERBY-965 still present in the old server, although now
manifested in a different way than with an old client, since the new
client correctly decodes the values transmitted:

SupportsResultSetConcurrency: TYPE_FORWARD_ONLY,CONCUR_READ_ONLY: false
SupportsResultSetConcurrency: TYPE_FORWARD_ONLY,CONCUR_UPDATABLE: true
SupportsResultSetConcurrency: TYPE_SCROLL_SENSITIVE,CONCUR_READ_ONLY: true

Wrong, of course.  The old client returned false for all of these.

That leaves the case of a (potential) new JCC driver and and old
server. I won't address that.

I hope this clarified matters in stead of muddling them further, the
details are a bit messy. Don't hesitate to ask if you have further


View raw message