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 would need to check further into that, however I think that by making
the new field for concurrency mode part of the identity of the
GenericStatement, the cache would be correct.
2. If the concurrency mode for the java.sql.Statement object is CONCUR_READ_ONLY, the
updatemode will be set to READ_ONLY. If the query string contains "for update"
an error will be thrown.
That would be incorrect.
1) Derby still needs to support positioned UPDATE and DELETE, in that
case it is fine to have a FOR UPDATE clause with a read only ResultSet.
You are right, it should not throw an error there.
I will modify the suggestion:
2. If the concurrency mode for the java.sql.Statement object is
CONCUR_READ_ONLY, the updatemode will be set to READ_ONLY if the
updateclause is unspecified or "for read only". If the query string
contains "for update" the updatemode is UPDATABLE, however the
java.sql.ResultSet.updateXXX methods throws an exception (if called)
since the resultset is not updatable.
2) Applications use the FOR UPDATE clause to control locking for
future updates with read only ResultSets.
Note currently it throws an exception if the statement is not updatable
i.e contains a join or order by.
-- Andreas
Dan.
