An update on this issue. It turned out to be a problem with our code. It looks like rc4 was actually not identifying this condition whereas 1.0 added a check to look for the locking condition when the update fails. So 1.0 was correctly throwing an exception. In any case, based on this mail, I have also explicitly added update-lock="true" in all my mappings.
Thanks for all the responses. Raghavan -----Original Message----- From: Pulat Yunusov [mailto:[EMAIL PROTECTED] Sent: Thursday, September 16, 2004 7:36 AM To: OJB Users List Subject: Re: Optimistic Locking exception with 1.0 - doesn't happen with rc4 Kollivakkam, Is the value in your MOD_NUM incremented properly every time the record is updated? I am asking because I have a problem using the version field for optimistic locking. Thanks, Pulat Kollivakkam R. Raghavan wrote: > No our application is one where client and server need to periodically > sync. Up. Instead of using time to figure out what has changed we use > a synchronization seq. number which the client and server exchange. > So this is not the locking col. The locking column is the MOD_NUM > column in the table. Thanks > Raghavan > > -----Original Message----- > From: Armin Waibel [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 16, 2004 12:34 AM > To: OJB Users List > Subject: Re: Optimistic Locking exception with 1.0 - doesn't happen with > rc4 > > > Hi Raghavan, > > do you increment the optimistic locking field by yourself with > > policy.setSyncSeqNum(SynchronizationLogic.getNextSynchronizationSequen > ce > Number().longValue()); > > ??Armin > OJB itself does increment/reset the locking field, if you increment > too, > > all the time a OLException will be thrown. > > regards > > > > Kollivakkam R. Raghavan wrote: > >>Yes! Happens all the time. My repository file is attached. I am >>using an integer version counter and set it up to have OJB provide the > > >>value. It happens, when I'm trying to execute the following code. The > > >>table declaration and the repository file are also attached. As you >>can see it's pretty vanilla OJB code - nothing fancy. >> >>----------------------- >>private static void savePolicyRecord(AbstractConfigPolicyData policy, >>AMCContext context) throws AMCException >> { >> PersistenceBroker broker = null; >> >> if (context != null && context.getUser() != null) { >> policy.setModifierId(context.getUser().getId()); >> } >> policy.setModificationTime(new Date()); >> >> >>policy.setSyncSeqNum(SynchronizationLogic.getNextSynchronizationSequen >>ce >>Number().longValue()); >> >> try >> { >> broker = >>PersistenceBrokerFactory.defaultPersistenceBroker(); >> broker.beginTransaction(); >> broker.store(policy); >> broker.commitTransaction(); >> >> } >> catch(PBFactoryException ex) >> { >> log.error(PB_FACTORY_EXCEPTION, ex); >> throw new AMCException(DATABASE_ERROR_KEY, ex, >>DATABASE_ERROR_CODE); >> } >> catch(PersistenceBrokerException ex) >> { >> log.error(PERSISTENCE_BROKER_EXCEPTION, ex); >> throw new AMCException(DATABASE_ERROR_KEY, ex, >>DATABASE_ERROR_CODE); >> } >> finally >> { >> if (broker != null) >> { >> broker.close(); >> } >> } >> } >> >>----------------- >> >>Table definition >>CREATE TABLE AMC_NODE_PSET >> ( >> ID int not null identity primary > > key, > >> MODIFICATION_TIME timestamp default 'now' not null, >> MODIFIER_ID int, >> MOD_NUM int not null, >> CREATED timestamp default 'now' not null, >> NODE_ID int, >> DR_ID int, >> GOLDEN_CONFIG_ID int, >> POLICY_TYPE varchar(4) not null, >> BUNDLE_TYPE int default '1' not null, -- > > '1' > >>- ama, '2' - aons >> CONFIG_STATE char not null, -- 'G' - Golden >>Config, 'A' - Add, 'M' - Modified, 'D' - Delete, 'R' - Archived. >> SYNC_SEQ_NUM bigint not null, >> DATA image, >> NAME varchar(64) not null, >> QNAME varchar(64) not null, >> DESCRIPTION varchar(64), >> EXT1 image, >> EXT2 varchar(64), >> EXT3 varchar(64), >> >> foreign key(NODE_ID) references AMC_AONS_NODE(ID), >> foreign key(DR_ID) references AMC_NODE_DR(ID), >> foreign key(MODIFIER_ID) references AMC_USER(ID) >> ); >> >>-----Original Message----- >>From: Brian McCallister [mailto:[EMAIL PROTECTED] >>Sent: Tuesday, September 14, 2004 6:14 PM >>To: OJB Users List >>Subject: Re: Optimistic Locking exception with 1.0 - doesn't happen > > with > >>rc4 >> >> >>I presume you can reliably replicate it, can you provide more >>information about when it is happening? >> >>Database, mapping for the optimistic TX field etc? >> >>There were a couple changes to optimistic tx's when using a timestamp >>instead of version counter. >> >>Any chance you can send a unit test which causes this to happen? If >>not, enough information on exactly when it happens so that I can do so > > >>would be appreciated! >> >>-Brian >> >>On Sep 14, 2004, at 8:03 PM, Kollivakkam R. Raghavan wrote: >> >> >> >>>I am getting the following exception with an optimistic locking which >>>does not happen with rc4. Did something change? We are about to use >>>OJB in production and I wanted to switch to the release version. >>>Please help. >>>Thanks Raghavan >>> >>> >>>------------------ >>> >>> >>> >>> at java.lang.Thread.run(Unknown Source) >>>Caused by: org.apache.ojb.broker.OptimisticLockException: Object has >>>been modifi ed by someone else >>> at >>>org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeUpdate(JdbcAc >>>cessImpl.java:485) >>> at >>>org.apache.ojb.broker.core.PersistenceBrokerImpl.storeToDb(Persistenc >>>eBrokerImpl.java:1641) >>> at >>>org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBro >>>kerImpl.java:1542) >>> at >>>org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBro >>>kerImpl.java:705) >>> at >>>org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(Delegati >>>ngPersistenceBroker.java:174) >>> at >>>org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(Delegati >>>ngPersistenceBroker.java:174) >>>a:1770) >>> ... 40 more >>> >>>Additional exceptions : >>> >>>14-Sep-2004 16:23:42 WARN [010-Processor25] >>>.broker.core.PersistenceBrokerImpl >>>No running tx found, please only store in context of an >>>PB-transaction, to avoid side-effects - e.g. when rollback of complex >> >> >>>objects 14-Sep-2004 16:23:42 ERROR [010-Processor25] Database error: >>>PersistenceBrokerException was caught >>>org.apache.ojb.broker.OptimisticLockException: Object has been >>>modified by someo ne else >>> at >>>org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeUpdate(JdbcAc >>>cessImpl.java:485) >>> at >>>org.apache.ojb.broker.core.PersistenceBrokerImpl.storeToDb(Persistenc >>>eBrokerImpl.java:1641) >>> at >>>org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBro >>>kerImpl.java:1542) >>> at >>>org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBro >>>kerImpl.java:705) >>> at >>>org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(Delegati >>>ngPersistenceBroker.java:174) >>> at >>>org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(Delegati >>>ngPersistenceBroker.java:174) >>> >>> >>>--------------------------------------------------------------------- >>>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] >> >> >> >>---------------------------------------------------------------------- >>-- >> >><class-descriptor class="com.cisco.aons.amc.data.NodePSet" >>table="AMC_NODE_PSET"> >> >> <field-descriptor >> name="id" >> autoincrement="true" >> primarykey="true" >> nullable="false" >> column="ID" >> jdbc-type="INTEGER"/> >> >> <field-descriptor >> name="modificationTime" >> nullable="false" >> column="MODIFICATION_TIME" >> jdbc-type="TIMESTAMP" >> >>conversion="org.apache.ojb.broker.accesslayer.conversions.JavaDate2Sql >>TimestampFieldConversion"/> >> >> <field-descriptor >> name="modifierId" >> column="MODIFIER_ID" >> jdbc-type="INTEGER"/> >> >> <field-descriptor >> name="modNum" >> nullable="false" >> column="MOD_NUM" >> jdbc-type="INTEGER" >> locking="true"/> >> >> <field-descriptor >> name="created" >> nullable="false" >> column="CREATED" >> jdbc-type="TIMESTAMP" >> > > conversion="org.apache.ojb.broker.accesslayer.conversions.JavaDate2SqlTi > mestampFieldConversion"/> > >> >> <field-descriptor >> name="nodeId" >> column="NODE_ID" >> jdbc-type="INTEGER"/> >> >> <field-descriptor >> name="drId" >> column="DR_ID" >> jdbc-type="INTEGER"/> >> >> <field-descriptor >> name="goldenConfigId" >> column="GOLDEN_CONFIG_ID" >> jdbc-type="INTEGER"/> >> >> <field-descriptor >> name="policyType" >> nullable="false" >> column="POLICY_TYPE" >> jdbc-type="VARCHAR" >> >>conversion="com.cisco.aons.amc.data.conversion.PolicyTypeConvertor"/> >> >> <field-descriptor >> name="bundleType" >> nullable="false" >> column="BUNDLE_TYPE" >> jdbc-type="INTEGER"/> >> >> <field-descriptor >> name="configState" >> nullable="false" >> column="CONFIG_STATE" >> jdbc-type="CHAR"/> >> >> <field-descriptor >> name="syncSeqNum" >> nullable="false" >> column="SYNC_SEQ_NUM" >> jdbc-type="BIGINT"/> >> >> <field-descriptor >> name="data" >> column="DATA" >> jdbc-type="VARBINARY"/> >> >> <field-descriptor >> name="name" >> nullable="false" >> column="NAME" >> jdbc-type="VARCHAR"/> >> >> <field-descriptor >> name="qualifiedName" >> nullable="false" >> column="QNAME" >> jdbc-type="VARCHAR"/> >> >> <field-descriptor >> name="description" >> column="DESCRIPTION" >> jdbc-type="VARCHAR"/> >> >> <field-descriptor >> name="ext1" >> column="EXT1" >> jdbc-type="VARBINARY"/> >> >> <field-descriptor >> name="ext2" >> column="EXT2" >> jdbc-type="VARCHAR"/> >> >> <field-descriptor >> name="ext3" >> column="EXT3" >> jdbc-type="VARCHAR"/> >> >></class-descriptor> --------------------------------------------------------------------- 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]
