db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik" <Dag.Wan...@Sun.COM>
Subject Re: conflict detection strategies
Date Thu, 16 Feb 2006 18:48:58 GMT

Hi,

>>>>> "Mike" == Mike Matrigali <mikem_app@sbcglobal.net> wrote:
Mike> 
Mike> To understand what is going on with these cursor deletes and updates
Mike> in SUR, could you explain what is done to execute each.  For example
Mike> for a delete there could be:
Mike> 1) position on rowlocation and just do delete
Mike> 2) position on rowlocation and check that all other fields match the
Mike>    row being deleted and do the delete
Mike> 3) execute delete from x where (provide matching columns for all columns).

1) is correct. The same goes for update. We do not try to check if
"others" (in the JDBC sense, although we do treat positioned
update/delete using the same cursor as "own", since it is so closely
related to result set operations in Derby) have modified the row.  If
the row has been deleted we generate a warning; positioned
update/delete will (in addition) return zero row count.

Thanks,
Dag

Mime
View raw message