db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fernanda Pizzorno (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-690) Add scrollable, updatable, insensitive result sets
Date Thu, 23 Feb 2006 09:42:26 GMT
    [ http://issues.apache.org/jira/browse/DERBY-690?page=comments#action_12367487 ] 

Fernanda Pizzorno commented on DERBY-690:

I hope this answers to some of your questions:

Read-uncommited isolation level does aquire locks for updatable forward-only result sets,
the same behavior has been kept on scrollable insensitve updatable result sets.

If a transaction attempts to delete a row that have previously been deleted (either in the
same trasaction, or by another transaction) a warning will be added to the result set (for
an updateRow or deleteRow call) or to the statement (for positioned SQL statements).

The update or delete is performed using positioned SQL statements as it has been done for
forward only ResultSets. The RowLocation is used when navigating to position the scan controller
at the correct row, and aquiring locks when necessary. Since the scan controller is positioned
on the correct row, and the necessary locks are aquired, it is possible to perform a positioned
SQL statement for both deletes and updates as it has been done for forward only result sets.

Positioned SQL statements are being used so the associated work on update or delete should
happen in the same way as for other positioned SQL statements. As mentioned when submitting
the patch, more tests will be written for SUR, and checking that the associated work is performed
on an update or delete, is part of the tests that are left to be written.

Two methods have been added to NoPutResultSet, updateCachedRow(ExecRow row) and markCachedRowAsDeleted(),
in order to view own changes. They are called from UpdateResultSet.open() and DeleteResultSet.open()
respectively and  they propagate the changes done to the current row to ScrollInsensitiveResultSet,
so that the hashtable can be updated.

"NOTE: Own changes means changes made by the result set itself, while other changes means
changes made by other transactions of other objects in the same transaction. " _ I think you
mean 'other transactions OR other objects in the same transaction'. That's correct, it is
supposed to be 'other transactions OR other objects in the same transaction'.

> Add scrollable, updatable, insensitive result sets
> --------------------------------------------------
>          Key: DERBY-690
>          URL: http://issues.apache.org/jira/browse/DERBY-690
>      Project: Derby
>         Type: New Feature
>   Components: JDBC
>     Reporter: Dag H. Wanvik
>     Assignee: Dag H. Wanvik
>     Priority: Minor
>  Attachments: DERBY-690-v1.diff, DERBY-690-v1.stat, SURChanges-v1.pdf, sur-proposal.txt,
> JDBC result sets are created with three properties: type, concurrency
> and holdability. The type can be one of TYPE_FORWARD_ONLY,
> be one of CONCUR_READ_ONLY and CONCUR_UPDATABLE. The holdability can
> JDBC allows the full cross product of these. SQL 2003 prohibits the
> combination is supported by some vendors, notably Oracle.
> Currently, Derby supports JDBC result sets in a limited
> way. Holdability is supported. Furthermore, the following is
> supported: 
> 	   - forward-only, read-only 
> 	   - forward-only, updatable (update, delete, but not insert)
> 	     Also, in the network driver, support for some data types
> 	     conversions is missing.
> 	   - scroll insensitive, read-only
> We (Fernanda and Andreas will cooperate with me on this) propose a
> plan to add support for the combination:
> 	   - scroll insensitive, updatable
> for both the embedded driver and the network client driver. 
> As a part of this we would also like to add the missing insert
> operation to the {forward-only, updatable} result sets (JIRA-100), and
> remove the requirement for an explicit "FOR UPDATE" clause in the SQL
> query to achieve updatability if CONCUR_UPDATABLE is specified
> (JIRA-231).
> The full proposal text is uploaded as an attachment, including a proposed
> functional specification.
> This JIRA will  be used to track sub-issues for this effort. The sub-issues will be linked
back to this issue.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message