Yes, what I meant is simply multiple updates on same table in one
transaction.
_________________________________________________________________________
Analyzed - ChangeFactory.getUpdateCommand() in JAVA DAS, has logic like this
-
if (updateCommand == null) {
...do something to create a new update command
}
else{
...just return the existing update command.
}
With this, in the current case, UpdateGenerator.INSTANCE.getUpdateCommand()
gets called only once instead of n times and all the returns from
ChangeFactory.getUpdateCommand() just return the same updateCommand which
is supposed to be only valid for first update command in current batch.
So when it comes to ChangeOperation.execute() - as
ChangeSummarizer.loadChanges() has done a correct while loop passing new
changedObject, the SET clause in UPDATE command gets correct param values,
BUT the WHERE clause gets just the parameter from the first UPDATE and thus
fails.
I have tried commenting the above if and checked that the updates happen
correctly.
So I am opening JIRA TUSCANY-1304, to fix this issue. Please let me know if
you think this change will have some other side effects or it is OK to do
the change.
_________________________________________________________________________
Yes :) this is an ancient problem, may be since the very first commit of
CompanyClient in trunk, I also got confused when I looked at it first. As
part of this new JIRA, I can fix this naming too.
_________________________________________________________________________
Regards,
Amita
On 5/26/07, Brent Daniel <[EMAIL PROTECTED]> wrote:
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/tuscany-dev@ws.apache.org/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]
