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/[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]
>
>
