By the way, it seems that in your code snip PB.abortTransaction() was never be called. This will cause an error log when call PB.close(), something like
"Broker is still in PB-transaction, do automatic abort before close!"
and OJB will internal do an PB.abortTransaction() call.


<snip>
try
        {
            broker =
PersistenceBrokerFactory.defaultPersistenceBroker();
            broker.beginTransaction();
            broker.store(policy);
            broker.commitTransaction();

        }
        catch(PBFactoryException ex)
        {
            log.error(PB_FACTORY_EXCEPTION, ex);
==========> broker.abortTransaction();
            throw new AMCException(DATABASE_ERROR_KEY, ex,
DATABASE_ERROR_CODE);
        }
        catch(PersistenceBrokerException ex)
        {
            log.error(PERSISTENCE_BROKER_EXCEPTION, ex);
==========> broker.abortTransaction();
            throw new AMCException(DATABASE_ERROR_KEY, ex,
DATABASE_ERROR_CODE);
        }
        finally
        {
            if (broker != null)
            {
                broker.close();
            }
        }
</snip>


Armin


Armin Waibel wrote:

Kollivakkam R. Raghavan wrote:

I am not using the ODMG API.  I do see a beginTransaction call in the
try/catch/finally block.  Is there something more I need to do.
Raghavan


It's independent from the used API, on each store/delete operation OJB check for a running PB-tx and if none found this message will be written.


<snip from PersistenceBrokerImpl class>
private void store(Object obj, Identity oid, ClassDescriptor cld, boolean insert)
{
if(!isInTransaction())
{
logger.warn("No running tx found, please only store in context of an PB-transaction" +
", to avoid side-effects - e.g. when rollback of complex objects");
}
....
</snip>


Similar check is made on PB.delete(...) call.
So somewhere in code you try to store an object without a running PB-tx.

Armin



-----Original Message-----
From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Thursday, September 16, 2004 1:00 AM
To: OJB Users List
Subject: Re: Optimistic Locking exception with 1.0 - doesn't happen with
rc4



oh, sorry

policy.setSyncSeqNum

seems to be mapped to column SYNC_SEQ_NUM, so the answer is no ;-)

So all things seem to be ok - strange. Method JdbcAccess#executeUpdate doesn't change much between rc4 and 1.0.1.


>>> 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

Seems you try to store objects without a running PB-tx, please fix this in your code.

Armin

Armin Waibel wrote:

Hi Raghavan,

do you increment the optimistic locking field by yourself with

policy.setSyncSeqNum(SynchronizationLogic.getNextSynchronizationSequen
ce
Number().longValue());

??
OJB itself does increment/reset the locking field, if you increment too,
all the time a OLException will be thrown.

regards
Armin


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.getNextSynchronizationSeque
nce
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.JavaDate2Sq
lTimestampFieldConversion"/>



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





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




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



Reply via email to