db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernt M. Johnsen" <Bernt.John...@Sun.COM>
Subject Re: [jira] Updated: (DERBY-825) writeSQLCAGRP() should use byte[] constants instead of Strings where feasible
Date Fri, 20 Jan 2006 13:31:59 GMT
Ok. I'll commit this one.

>>>>>>>>>>>> Dyre.Tjeldvoll@Sun.COM wrote (2006-01-20
14:15:34):
> >>>>> "BP" == Bryan Pendleton <bpendleton@amberpoint.com> writes:
> 
>     BP> Dyre Tjeldvoll (JIRA) wrote:
>     >>> A solution is to keep the commonly used SQLStates as byte[] constants
that can be inserted into the message with writeBytes().
> 
>     BP> I think that the solution shows great promise, but the patch
>     BP> that you provided seems too "open coded" for me.
> 
>     BP> It seems to me that the recently-added DRDAString class could
>     BP> be used as the encapsulation vehicle for this String/byte[]
>     BP> caching stuff, so that the bulk of the DRDA code didn't have
>     BP> to be so involved in the details of when to use the string and
>     BP> when to use the byte array.
> 
>     BP> So instead of seeing a bunch of changes like:
> 
>     BP> -		writer.writeString(server.prdId);
>     BP> +        // Write the byte[] constant rather than the string, for efficiency
>     BP> +        writer.writeBytes(server.prdIdBytes_);
> 
>     BP> which seems to mean that we'd have to maintain constant vigilance
>     BP> into the future to make sure that we know when to use the String
>     BP> versus when to use the byte[], it seems like we should turn an
>     BP> object like server.prdId into a DRDAString, and then let DDMWriter
>     BP> and DRDAString work out the details themselves about whether to use
>     BP> the String or the byte[].
> 
>     BP> Does this make any sense? Am I barking up the wrong tree?
> 
> I see your point, and was thinking along these lines for a while. I
> was thinking about making a String replacement that kept a String and
> a byte[] internally and did the conversion on demand and cached the
> result. 
> 
> But then I decided that such a solution would provide much more
> functionality than what was needed. Keep in that these values are in
> fact constants, and they are not used for anything other than filling
> messages, and so, unlike DRDAStrings, they don't need a String
> interface. The DRDAStrings need to work as Strings AND be compared
> efficiently to a segment of a byte array. 
> 
> I see that such a WrapperString clould be useful for future work, but
> it also has its problems. Using a replacement for String is tedious
> since you cannot extend the String class. You have to create a wrapper
> (like DRDAString) and change the signature of every method that
> takes a String argument to take the WrapperString as argument. And
> frequently you'll still need to provide an overload for String as
> well.
> 
> Also, if you want to be able to use your String replacement generally
> you have to come up with a place to put it. And as the "sharing common
> code" discussions have shown, that is not always as easy as it
> sounds... 
> 
> To conclude, I will not implment and use such a data type for this
> patch (it is not my itch), but others should feel free to do so.
> 
> (For the record, I would not have replaced Strings with byte[], if was
> not for the fact that the profiler told me that this was a hotspot)
> 
> 
> -- 
> dt
> 
> However, experience shows that for many people and many applications a
> dose of paranoia is reasonable - Bjarne Stroustrup
> 

-- 
Bernt Marius Johnsen, Database Technology Group, 
Staff Engineer, Technical Lead Derby/Java DB
Sun Microsystems, Trondheim, Norway

Mime
View raw message