tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amita Vadhavkar" <amita.vadhav...@gmail.com>
Subject [DAS] Erroneous behavior when PK's value is updated using applyChanges()
Date Wed, 04 Apr 2007 12:00:35 GMT
Hi All,


In addition to the problem mentioned in below link,
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16304.html

Found one more issue when tried to have a PK on the same table
OrderDetails{ORDER_ID, PRODUCT_ID, PRICE} , PK - ORDER_ID
And update is attempted to update ORDER_ID to a new value (1->10) using
applyChanges().

Now the scene in UpdateGenerator.getUpdateCommand(), takes into account the
PK list
(which is not zero now) and forms a update statement as

update ORDERDETAILS set ORDER_ID = ? where ORDER_ID = ?  and ORDER_ID = ?

Here in the where clause - 2nd ORDER_ID param is marked as collision param
but
first ORDER_ID param is not.

Due to this, in ChangeOperation.execute(), the 1st ORDER_ID param in where
clause calls
setValue() and 2nd ORDER_ID param in where clause does not (as its
collision).

So the final statement becomes:- e.g.

update ORDERDETAILS set ORDER_ID = 10 where ORDER_ID = 10 and ORDER_ID = 1

This results in "An update collision occurred "-
OptimisticConcurrencyException.

To avoid this problem, in UpdateGenerator.getUpdateCommand(), in the PK list
iteration
part, we need to check for collision, as we are checking in the later code
and set value
of the param in where clause, if collision is the case indeed.
Or have additional intelligence in the update generation logic to avoid
where clauses
like where ORDER_ID = ?  and ORDER_ID = ? , by omitting duplications

Please let me know what is a right approach and if it needs a JIRA+patch.

Regards,

Amita

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message