db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: PreparedStatement.setXXX methods do not set up ContextStack. Is that right and if so, why?
Date Tue, 06 Mar 2007 16:28:26 GMT
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.


Mime
View raw message