You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Mamta Satoor <ms...@gmail.com> on 2007/03/03 10:18:55 UTC
PreparedStatement.setXXX methods do not set up ContextStack. Is that right and if so, why?
Hi,
I noticed that PreparedStatement.executeQuery(like several other JDBC
methods) sets up the context stack by calling setupContextStack in
EmbeddedStatement's executeStatement method(line 1118). But when setXXX
methods are called on PreparedStatement, we do not create a context stack.
Why do we not need the context setting for setXXX methods?
The reason for my question is I ran following simple query in ij
connect 'jdbc:derby:c:/dellater/db1';
CREATE TABLE TSTAB (I int, STATUS_TS Timestamp, PROPERTY_TS Timestamp);
prepare p as 'select STATUS_TS from tstab where status_ts = ?';
execute p using 'values (''20'')';
When trying to debug through the last statement above ***execute p using
'values (''20'')';***, I found that we reach SQLTimestamp.setValue(String
theValue) method. In this method, we try to determine the locale by going
through the Context stack but since none was setup for setXXX methods, we
always use a null locale irrespective of what territory the database was
created with. That doesn't seem like the right thing to do and the reason
this is happening is because no context stack was set up for this particular
JDBC api.
I am not very familiar with context stack and maybe what Derby is doing here
is the right thing to do but I would like to understand why Derby is coded
the way it is for PreparedStatement.setXXX methods. Any feedback will be
very helpful.
thanks,
Mamta
Re: PreparedStatement.setXXX methods do not set up ContextStack. Is that right and if so, why?
Posted by Mamta Satoor <ms...@gmail.com>.
Dan, did you mean EmbedPreparedStatement.setDate(...)?
Mamta
On 3/3/07, Daniel John Debrunner <dj...@apache.org> wrote:
>
> Daniel John Debrunner wrote:
>
> > Sounds like a bug. I do think that the existing code that obtains the
> > locale is approaching the problem in entirely the wrong way and probably
> > should be written from scratch. E.g. if a data type is locale dependent
> > for its string conversion then it should have a setValue(String) method
> > that has an additional argument that specifies the locale (either as a
> > Locale, a LocaleFinder or some other effective object).
>
> An example of this is the way Calendar objects are passed into the
> EmbedResultSet.setDate(...) methods and onto the data types.
>
> Dan.
>
>
Re: PreparedStatement.setXXX methods do not set up ContextStack.
Is that right and if so, why?
Posted by Daniel John Debrunner <dj...@apache.org>.
Daniel John Debrunner wrote:
> Sounds like a bug. I do think that the existing code that obtains the
> locale is approaching the problem in entirely the wrong way and probably
> should be written from scratch. E.g. if a data type is locale dependent
> for its string conversion then it should have a setValue(String) method
> that has an additional argument that specifies the locale (either as a
> Locale, a LocaleFinder or some other effective object).
An example of this is the way Calendar objects are passed into the
EmbedResultSet.setDate(...) methods and onto the data types.
Dan.
Re: PreparedStatement.setXXX methods do not set up ContextStack.
Is that right and if so, why?
Posted by Daniel John Debrunner <dj...@apache.org>.
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.
Re: PreparedStatement.setXXX methods do not set up ContextStack.
Is that right and if so, why?
Posted by Mike Matrigali <mi...@sbcglobal.net>.
From the function spec I thought that this project was simply going to
implement TERRITORY_BASED ordering - and not anything to do with
changing string representation of datatypes based on the TERRITORY.
So I was expecting only the compare routines to be affected.
Is the problem that some dormant code is going to be enabled as a side
effect when the ordering changes go in?
Mamta Satoor wrote:
> Let me throw out my thoughts on how I am thinking of implementing locale
> based ordering.
>
> Since the goal is to not penalize the default mode of ordering, which is
> UCS_BASIC, I am thinking that at the compile phase of a sql statement,
> if we are dealing with a database with TERRITORY_BASED ordering, then I
> will create super classes of char datatypes and these super classes will
> use the locale info in their ordering sensitive methods which would be
> methods like "like", string compare etc. So, these superclasses will
> look a little bit like existing disabled national char datatypes but
> will not have all the methods from the existing national char datatypes.
> This way, the existing char datatypes will not have to know about
> language based ordering and it will all be handled in the special
> classes if user has asked for TERRITORY_BASED ordering.
>
> I have to admit that I had assumed that locale info is already available
> to the datatypes since the working National character type
> implementation was already part of Derby except that it was disabled. I
> had assumed that the locale info which is already available in the Derby
> code will be simply used by the super classes of char datatypes. I had
> not forseen the current problem of finding an efficient way of getting
> the locale information to the datatypes. Which is fine because I do see
> that it is important from Derby's performance point of view.
>
> Please let me know what you think of the my design thoughts.
> thanks,
> Mamta
>
> ps
> Also, in my earlier mail today, when I said that the solution that is
> coming to my mind is context based, I didn't mean to push and pop the
> contexts for setString methods because I realize that we have to pay
> high penalty in terms of performance for the entire context pushing and
> popping. Instead, I was thinking of having this special context on the
> context stack for each booted database in the system which is never
> popped out and just has the locale information in it and the locale
> sensitive methods will somehow get that locale info from the context
> stack. I have not gone the route of implementing it to know what is
> involved for a solution like that.
>
>
> On 3/6/07, *Daniel John Debrunner* <djd@apache.org
> <ma...@apache.org>> wrote:
>
> 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. Maybe there are some other solutions too which
> I am
> > not able to visulaize at this point.
>
> Is there a list of logical operations/method calls/classes that need
> locale based information, and what type of information they need?
>
> Is there some design or thoughts on how locale based ordering
> (DERBY-1478) is going to be implemented?
>
> I'm not sure I understand the scope of the problem here.
>
> Dan.
>
>
Re: PreparedStatement.setXXX methods do not set up ContextStack. Is that right and if so, why?
Posted by Mamta Satoor <ms...@gmail.com>.
Let me throw out my thoughts on how I am thinking of implementing locale
based ordering.
Since the goal is to not penalize the default mode of ordering, which is
UCS_BASIC, I am thinking that at the compile phase of a sql statement, if we
are dealing with a database with TERRITORY_BASED ordering, then I will
create super classes of char datatypes and these super classes will use the
locale info in their ordering sensitive methods which would be methods like
"like", string compare etc. So, these superclasses will look a little bit
like existing disabled national char datatypes but will not have all the
methods from the existing national char datatypes. This way, the existing
char datatypes will not have to know about language based ordering and it
will all be handled in the special classes if user has asked for
TERRITORY_BASED ordering.
I have to admit that I had assumed that locale info is already available to
the datatypes since the working National character type implementation was
already part of Derby except that it was disabled. I had assumed that the
locale info which is already available in the Derby code will be simply used
by the super classes of char datatypes. I had not forseen the current
problem of finding an efficient way of getting the locale information to the
datatypes. Which is fine because I do see that it is important from Derby's
performance point of view.
Please let me know what you think of the my design thoughts.
thanks,
Mamta
ps Also, in my earlier mail today, when I said that the solution that is
coming to my mind is context based, I didn't mean to push and pop the
contexts for setString methods because I realize that we have to pay high
penalty in terms of performance for the entire context pushing and popping.
Instead, I was thinking of having this special context on the context stack
for each booted database in the system which is never popped out and just
has the locale information in it and the locale sensitive methods will
somehow get that locale info from the context stack. I have not gone the
route of implementing it to know what is involved for a solution like that.
On 3/6/07, Daniel John Debrunner <dj...@apache.org> wrote:
>
> 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. Maybe there are some other solutions too which I am
> > not able to visulaize at this point.
>
> Is there a list of logical operations/method calls/classes that need
> locale based information, and what type of information they need?
>
> Is there some design or thoughts on how locale based ordering
> (DERBY-1478) is going to be implemented?
>
> I'm not sure I understand the scope of the problem here.
>
> Dan.
>
>
Re: PreparedStatement.setXXX methods do not set up ContextStack.
Is that right and if so, why?
Posted by Daniel John Debrunner <dj...@apache.org>.
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. Maybe there are some other solutions too which I am
> not able to visulaize at this point.
Is there a list of logical operations/method calls/classes that need
locale based information, and what type of information they need?
Is there some design or thoughts on how locale based ordering
(DERBY-1478) is going to be implemented?
I'm not sure I understand the scope of the problem here.
Dan.
Re: PreparedStatement.setXXX methods do not set up ContextStack. Is that right and if so, why?
Posted by Mamta Satoor <ms...@gmail.com>.
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. Maybe there are some other
solutions too which I am not able to visulaize at this point.
I will keep looking more for other ways of getting handle of locale info to
pass on to locale sensitive methods but am I missing some other easier
possible solution to pass the locale info to locale sensitivie methods of
datatypes?
Mamta
On 3/5/07, Daniel John Debrunner <dj...@apache.org> wrote:
>
> Mamta Satoor wrote:
> > Another solution that I have been thinking of is to have the locale
> > dependents datatypes by aware of their locale so they can use that
> > locale information in their locale sensitive methods. So, for eg, in the
> > ij script example that we are discussing, SQLTimestamp in it's
> > constructor should get the Locale/LocaleFinder/some other effective
> > object (copying Dan's line literally here) and locale sensitive methods
> > like setValue can simply find the locale info in it's class itself.
> >
> > So, in other words, rather than passing the locale info to the locale
> > sensitive methods, pass it to the locale sensitive datatype in it's
> > constructor and use that locale info in all the locale sensitive methods
> > in that datatype class.
>
> I think there are a couple of issues with this approach:
>
> - the size in memory of each instance of a value (e.g. SQLTimestamp)
> will increase. Passing in the value will only increase a single object
> (e.g. the activation or language connection context). Imagine a query
> that performs a lot of manipulation of timestamp values.
>
> - How to handling reading the value from disk? Would information about
> the locale need to be stored on disk to allow the object to be recreated
> correctly? Thus increasing on-disk size? (and upgrade issues?).
>
> Dan.
>
> Dan.
>
>
Re: PreparedStatement.setXXX methods do not set up ContextStack.
Is that right and if so, why?
Posted by Daniel John Debrunner <dj...@apache.org>.
Mamta Satoor wrote:
> Another solution that I have been thinking of is to have the locale
> dependents datatypes by aware of their locale so they can use that
> locale information in their locale sensitive methods. So, for eg, in the
> ij script example that we are discussing, SQLTimestamp in it's
> constructor should get the Locale/LocaleFinder/some other effective
> object (copying Dan's line literally here) and locale sensitive methods
> like setValue can simply find the locale info in it's class itself.
>
> So, in other words, rather than passing the locale info to the locale
> sensitive methods, pass it to the locale sensitive datatype in it's
> constructor and use that locale info in all the locale sensitive methods
> in that datatype class.
I think there are a couple of issues with this approach:
- the size in memory of each instance of a value (e.g. SQLTimestamp)
will increase. Passing in the value will only increase a single object
(e.g. the activation or language connection context). Imagine a query
that performs a lot of manipulation of timestamp values.
- How to handling reading the value from disk? Would information about
the locale need to be stored on disk to allow the object to be recreated
correctly? Thus increasing on-disk size? (and upgrade issues?).
Dan.
Dan.
Re: PreparedStatement.setXXX methods do not set up ContextStack. Is that right and if so, why?
Posted by Mamta Satoor <ms...@gmail.com>.
Another solution that I have been thinking of is to have the locale
dependents datatypes by aware of their locale so they can use that locale
information in their locale sensitive methods. So, for eg, in the ij script
example that we are discussing, SQLTimestamp in it's constructor should get
the Locale/LocaleFinder/some other effective object (copying Dan's line
literally here) and locale sensitive methods like setValue can simply find
the locale info in it's class itself.
So, in other words, rather than passing the locale info to the locale
sensitive methods, pass it to the locale sensitive datatype in it's
constructor and use that locale info in all the locale sensitive methods in
that datatype class.
How does this sound?
Mamta
On 3/3/07, Daniel John Debrunner <dj...@apache.org> wrote:
>
> Mamta Satoor wrote:
> ******part of mail snipped here******
> The reason for my question is I ran following simple query in ij
> > connect 'jdbc:derby:c:/dellater/db1';
> > CREATE TABLE TSTAB (I int, STATUS_TS Timestamp, PROPERTY_TS Timestamp);
> > prepare p as 'select STATUS_TS from tstab where status_ts = ?';
> > execute p using 'values (''20'')';
> >
> > When trying to debug through the last statement above ***execute p using
> > 'values (''20'')';***, I found that we reach
> > SQLTimestamp.setValue(String theValue) method. In this method, we try to
> > determine the locale by going through the Context stack but since none
> > was setup for setXXX methods, we always use a null locale irrespective
> > of what territory the database was created with. That doesn't seem like
> > the right thing to do and the reason this is happening is because no
> > context stack was set up for this particular JDBC api.
>
> Sounds like a bug. I do think that the existing code that obtains the
> locale is approaching the problem in entirely the wrong way and probably
> should be written from scratch. E.g. if a data type is locale dependent
> for its string conversion then it should have a setValue(String) method
> that has an additional argument that specifies the locale (either as a
> Locale, a LocaleFinder or some other effective object).
>
> Dan.
>
>
Re: PreparedStatement.setXXX methods do not set up ContextStack.
Is that right and if so, why?
Posted by Daniel John Debrunner <dj...@apache.org>.
Mamta Satoor wrote:
> Hi,
>
> I noticed that PreparedStatement.executeQuery(like several other JDBC
> methods) sets up the context stack by calling setupContextStack in
> EmbeddedStatement's executeStatement method(line 1118). But when setXXX
> methods are called on PreparedStatement, we do not create a context
> stack. Why do we not need the context setting for setXXX methods?
Pushing and popping the context stack is an expensive operation,
requiring to do this on every setXXX() call would have a severe
performance impact on Derby. Setting (and getting) values should be
simply setting a value in a DataValueDescriptor and thus has no need to
setup the context.
> The reason for my question is I ran following simple query in ij
> connect 'jdbc:derby:c:/dellater/db1';
> CREATE TABLE TSTAB (I int, STATUS_TS Timestamp, PROPERTY_TS Timestamp);
> prepare p as 'select STATUS_TS from tstab where status_ts = ?';
> execute p using 'values (''20'')';
>
> When trying to debug through the last statement above ***execute p using
> 'values (''20'')';***, I found that we reach
> SQLTimestamp.setValue(String theValue) method. In this method, we try to
> determine the locale by going through the Context stack but since none
> was setup for setXXX methods, we always use a null locale irrespective
> of what territory the database was created with. That doesn't seem like
> the right thing to do and the reason this is happening is because no
> context stack was set up for this particular JDBC api.
Sounds like a bug. I do think that the existing code that obtains the
locale is approaching the problem in entirely the wrong way and probably
should be written from scratch. E.g. if a data type is locale dependent
for its string conversion then it should have a setValue(String) method
that has an additional argument that specifies the locale (either as a
Locale, a LocaleFinder or some other effective object).
Dan.