Amita,
I'm a little confused by your use of the term "batch update". Usually
this would refer to the JDBC batch update capability, which is a
performance enhancement that allows a PreparedStatement to be executed
multiple times with different parameters. But, from your note I think
you are referring to the ability to make several updates in the same
transaction. Am I understanding you correctly?
I'm also a little confused by the scenario and why it's failing. Is
this the scenario in CompanyClient.changeFirstCompanyDepartmentNames()
where you read a company and its departments and then update each
department name? If so, there is no reason this should be failing, and
if it is there's a major bug somewhere. The automatic OCC control
works by generating an overqualified update statement using the old
values from the DataObject. If you're seeing something like:
update department set name='xyz' where id=1 and name='Advanced Technologies'
update department set name='xyz' where id=2 and name='Advanced Technologies'
update department set name='xyz' where id=3 and name='Advanced Technologies'
Where Departments 2 and 3 previously had names other than "Advanced
Technologies", then something is wrong. I would check to see that the
SDO function to get the old values of the DataObject is working
correctly. This is pretty basic function, so I'm not sure it's a good
idea for the sample to work around it.
On a side note, CompanyClient is somewhat confusing because most of
the variable names are referring to customers, though no "customer"
data is involved in the sample. Also, I'm wondering how dbconfig is
handling foreign keys? It looks like it is manually entering company
IDs for departments rather than using the generated value for a
company. Is there somewhere else where foreign key assignments are
handled?
Brent
On 5/24/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
Hello Luciano,
In the companyweb integration with dbconfig - update and delete was
not working for
the below reason:-
The config for dbconfig util had
1><Table name="DEPARTMENT" SQLCreate="CREATE TABLE DEPARTMENT (ID INT
PRIMARY KEY NOT NULL GENERATED ALWAYS AS IDENTITY, NAME
VARCHAR(30),LOCATION VARCHAR(30), DEPNUMBER VARCHAR(10),COMPANYID
INT)">
<row>'Advanced Technologies', 'NY', '123', 1</row>
<row>'Default Name 2', '', '', 1</row>
<row>'Default Name 3', '', '', 1</row>
<row>'Default Name 4', '', '', 1</row>
<row>'Default Name 5', '', '', 1</row>
<row>'Default Name 6', '', '', 1</row>
<row>'Default Name 7', '', '', 1</row>
<row>'Default Name 8', '', '', 1</row>
</Table>
Changing it to below, made update and delete to succeed
2><Table name="DEPARTMENT" SQLCreate="CREATE TABLE DEPARTMENT (ID INT
PRIMARY KEY NOT NULL GENERATED ALWAYS AS IDENTITY, NAME
VARCHAR(30),LOCATION VARCHAR(30), DEPNUMBER VARCHAR(10),COMPANYID
INT)">
<row>'Advanced Technologies', 'NY', '123', 10</row>
<row>'Default Name', '', '', 1</row>
<row>'Default Name', '', '', 1</row>
<row>'Default Name', '', '', 1</row>
<row>'Default Name', '', '', 1</row>
<row>'Default Name', '', '', 1</row>
<row>'Default Name', '', '', 1</row>
<row>'Default Name', '', '', 1</row>
</Table>
This is because, DAS at present does not support batch update. So, in
the original config,1>
when update department name for companyid 1 was fired, the statements
formed were
update department set name='xyz' where id=1 and name='Advanced Technologies'
update department set name='xyz' where id=2 and name='Advanced Technologies'
update department set name='xyz' where id=3 and name='Advanced Technologies'
...
Now as there is no matching row, for id=2 and name='Advanced Technologies',
OptimisticWriteCommandImpl.basicExecute() was giving 0 rowsAffected and thus
OCC Exception that update collision occured.
With changed to 2>, the where clause works correct by luck as all old values
are 'Default Name'.
So, the proper solution will be restricting only one update statement
to be fired
instead of batch update/delete. This will need change in
CompanyClient.changeFirstCompanysDepartmentNames()
and CompanyClient.deleteDepartmentsFromFirstCompany().
DAS by design calls one updateGenerator.getUpdateCommand() for one
applyChanges() and sets the values of collision param in it.
So, if there is batch , it can not do batch updates with proper values
in where clauses.
It looks like this can be covered under JIRAs created for Tuscany DAS
Features/Questions -
http://www.mail-archive.com/[email protected]/msg17813.html
Regards,
Amita
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
