[ http://issues.apache.org/jira/browse/DERBY-825?page=all ] Bernt M. Johnsen resolved DERBY-825: ------------------------------------
Resolution: Fixed Comitted as #370806 Fri Jan 20 14:34:53 CET 2006 bernt The log message errouneous and ended up under DERBY-815. > writeSQLCAGRP() should use byte[] constants instead of Strings where feasible > ----------------------------------------------------------------------------- > > Key: DERBY-825 > URL: http://issues.apache.org/jira/browse/DERBY-825 > Project: Derby > Type: Sub-task > Components: Network Server, Performance > Reporter: Dyre Tjeldvoll > Assignee: Dyre Tjeldvoll > Priority: Minor > Attachments: derby-825.diff, derby-825.stat, derbynetclientmats_report.txt > > writeSQLCAGRP() writes Strings into the message being built. Profiling shows > that it is more expensive to write a String than a byte[] because the String > must be converted to UTF8. writeSQLCAGRP() writes 5 bytes for SQLState, and > this is done by either writing a String constant, or the return value from > SQLException.getSQLState(). For the common case where there is no exception > (SQLState = 5xspace), or the exception is a "dummy" exception (SQLState=00000 > or 02000, End of Data), this is wasteful because the String has to be > converted to byte[] each time, and in the case of the dummy exception, a new > String object will be created each time getSQLState() is called, even if the > exception object is the same (there is no caching, which is reasonable since > exceptions are meant to be thrown, not kept around for a long time). > A solution is to keep the commonly used SQLStates as byte[] constants that > can be inserted into the message with writeBytes(). > If writeSQLCAGRP() is called with no SQLException (null) there is no attempt > to put an internationalized error message into the outgoing message (The > third argument to writeSQLCAXGRP() is null). This is reasonable, but the same > optimization is not done when the exception is one of the dummy exceptions > mentioned previously. In this case an internationalized version of the > message "End of Data" is constructed and inserted into the message. It would > be better to call writeSQLCAXGRP(..,null,..) in this case as well, since it > isn't needed by the client in this case. > Finally, writeSQLCAERRWARN() uses writeScalarPaddedBytes() to write values > that also can be stored as byte[] constants, and written faster with > writeBytes() > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira