db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mamta Satoor <msat...@gmail.com>
Subject Re: [jira] Commented: (DERBY-231) "FOR UPDATE" required for updatable result set to work
Date Thu, 27 Oct 2005 17:56:44 GMT
On 10/27/05, Daniel John Debrunner <djd@debrunners.com> wrote:
>
> Andreas Korneliussen (JIRA) wrote:
>
> > [
> http://issues.apache.org/jira/browse/DERBY-231?page=comments#action_12356096]
> >
> > Andreas Korneliussen commented on DERBY-231:
> > --------------------------------------------
> >
> > Currently, the updatemode for the resultset node is determined in the
> bind() phase of the query compilation. If the updatability clause is
> unspecified, the updatemode is set to READ_ONLY.
> >
> > To get rid of the requirement of having "for update" in the query
> string, I plan doing the following :
> >
> > 1. In the bind() phase, the nodes do currently not have any information
> about the concurrency mode for the java.sql.Statement object. I would like
> to provide a mechanism to bring it down to the compiler by adding a field to
> the StatementContext object.
>
> How this interacts with the statement cache needs to be considered. The
> current statement cache is lookup by current schema and text of the
> query string. You may be going in a direction where the same text
> 'SELECT * FROM T' leads to different plans depending on the updatable
> state of the result set.
>
> >

 I am glad that work is being done to get rid of "FOR UPDATE" in the query
string. When I implemented updatable resultset(My itch at that point was to
provide an implementation for updatable resultset in its simplest/quickest
form which menat requiring FOR UPDATE), the statement caching was the reason
that I decided to require FOR UPDATE clause so I could distinguish between a
read only resutlset and updatable resultset. So just to reiterate Dan's
point, do look for statement caching issue.
Mamta

Mime
View raw message