Mamta Satoor wrote:
I have spent some time exploring the code to see how the Locale info can
be passed to a datatype's locale sensitive methods. What I am finding is
that these locale sensitive methods, for instance setValue method in
datatype like SQLTime, get called from many different places in the
Derby code. Now, I might be single tracking my thoughts here, but it
seems to me that context stack might be the right way for these
different callers to get handle of locale info and pass it to the
setValue methods.
There's some background on the current context manager & switching
approach in slides 33-36 of:
http://db.apache.org/derby/binaries/ApacheDerbyInternals_1_1.pdf
Basically pushing and popping the context stack is expensive and ideally
the code would only do it when it was required. That is when some
stateless mapping to the current connection is needed. The current code
too often takes the easy approach and fetches information using this
stateless mapping.
I think there is one actual place when a stateless mapping is really
required, when executing
DriverManager.getConnection("jdbc:default:connection")
in a server-side routine.
If the code could be improved so that the stateless mapping was limited
to the above situation, then the performance of Derby could be improved.
E.g. there would no longer be any need to push and pop the context
manager on every significant JDBC call. The pushing & popping could be
optimized on routine invocation so that it was not invoked for NO SQL
routines, thus improving Derby's performance for simple Java routines.
Thus adding more stateless mapping for locale based operations seem to
take the code further away from being able to gain performance, and most
likely will degrade performance as it will require pushing and popping
the context manager on EmbedPreparedStatement.setString(), which is a
very common call for JDBC applications.
Dan.
