On 10/27/05, Daniel John Debrunner <[EMAIL PROTECTED]> 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
