So, I also think there is a bug somewhere, but I don't think I can spend much time on this until Tuesday, as I have limited connectivity for the next couple days.
On 5/25/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?
Yes, I also don't think I'm trying to do anything out of the ordinary here, I haven't changed any code on the companyWeb or DAS, the only different thing here is the database, where I'm using dbConfig instead of the canned derby db from svn. The database also have small differences on the data, where each department now have a distinct name, and I think this is what is causing the problem (maybe uncovering a bug)
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:
Yes, this is the scenario, I think before, as the department names had all same name, we were not seeing any issue, and now as I changed the department names to have distinct names, I started seeing the issue, but I really didn't have time to look much more after I saw the issue
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.
Humm, good point, we recently had issues on SDO ChangeSummary and several DAS testcases were failing, but at least that part is fixed thanks to Kelvin, but it's a good point to check there.
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?
The current impl is using generated PK, but just assuming (guessing) FKs. Just in case, I have attached the patch on the following jira [1] and steps on how to reproduce the issue [1] https://issues.apache.org/jira/browse/TUSCANY-1300
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]
-- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
