AW: [ojb-users] ODMG Cascading Updates : possible/probable bug.

[Mahler T. <tho...@it...>]

Hi Charles,

> Hi Again,
> 
> Has anyone been able to have a quick look at this yet ? 

Not yet. I added it to my ever growing todo list...

> Either we're making
> an obvious and silly mistake, or there is a fundamental error 
> in the ODMG
> transaction code, which could have big consequences.
> 

I assume it's a OJB bug. Thus I really appreciate your contribution of a
complete testcase which will help to hunt it down.

cu,

Thomas

> Thanks,
> 
> Charles.
> 
> > -----Original Message-----
> > From: Charles Anthony [mailto:cha...@hp...]
> > Sent: 08 April 2002 13:18
> > To: 'obj...@li...'
> > Cc: 'tho...@it...'
> > Subject: [ojb-users] ODMG Cascading Updates : possible/probable bug.
> > 
> > 
> > Hello All,
> > 
> > In OJB-0.8.375, cascading updates appears to be broken when 
> > using ODMG.
> > 
> > A colleague and I have managed to abstract the problem into a 
> > simple test
> > case.
> > test.ClassA has a collection of test.ClassB
> > test.ClassB has a reference back to test.ClassA
> > i.e. a simple bi-directional 0..n relationship between ClassA 
> > and ClassB.
> > 
> > We create an instance of ClassA, and add an instance of 
> ClassB to the
> > classBs Collection; we then lock the instance of ClassA for 
> write, and
> > commit the transaction.
> > 
> > Extract :
> > ClassA a1 = new ClassA("A 1");
> > ClassB b1 = new ClassB("B 1");
> > a1.getClassBs().add(b1);
> > 
> > Transaction tx = null;
> > tx = odmg.newTransaction();
> > tx.begin();
> > tx.lock(a1, tx.WRITE);
> > tx.commit();
> > 
> > When the transaction is committed, the ClassA row is 
> > correctly inserted into
> > the database, and ClassB row is also inserted into the database.
> > Unfortunately, it is inserted twice, resulting in a Primary 
> > key violation
> > (I've remove the primary key constraint in the attatched SQL).
> > 
> > It is some time since I've been able to spend anytime on OJB, 
> > and so my
> > knowledge of its internals has faded somewhat. However, by 
> > stepping through
> > in debug, it seems that the the ClassB instance is committed 
> > twice, once in
> > the collection and once on it's own.
> > 
> > I attach the test case, the repository_user.xml and the SQL 
> > to create the
> > tables. We're using SQL Server, but I'm fairly sure this is 
> a platform
> > independent problem.
> > 
> > Are we doing something wrong, or is this a bug ?
> > 
> > Thanks,
> > 
> > Charles.
> > 
> > 
> > 
> > This email and any attachments are strictly confidential and 
> > are intended
> > solely for the addressee. If you are not the intended 
> > recipient you must
> > not disclose, forward, copy or take any action in reliance on 
> > this message
> > or its attachments. If you have received this email in error 
> > please notify
> > the sender as soon as possible and delete it from your 
> > computer systems.
> > Any views or opinions presented are solely those of the 
> > author and do not
> > necessarily reflect those of HPD Software Limited or its affiliates.
> > 
> >  At present the integrity of email across the internet cannot 
> > be guaranteed
> > and messages sent via this medium are potentially at risk.  
> > All liability
> > is excluded to the extent permitted by law for any claims 
> > arising as a re-
> > sult of the use of this medium to transmit information by or to 
> > HPD Software Limited or its affiliates.
> > 
> > 
> >           
> > 
> > 
> 
> 
> This email and any attachments are strictly confidential and 
> are intended
> solely for the addressee. If you are not the intended 
> recipient you must
> not disclose, forward, copy or take any action in reliance on 
> this message
> or its attachments. If you have received this email in error 
> please notify
> the sender as soon as possible and delete it from your 
> computer systems.
> Any views or opinions presented are solely those of the 
> author and do not
> necessarily reflect those of HPD Software Limited or its affiliates.
> 
>  At present the integrity of email across the internet cannot 
> be guaranteed
> and messages sent via this medium are potentially at risk.  
> All liability
> is excluded to the extent permitted by law for any claims 
> arising as a re-
> sult of the use of this medium to transmit information by or to 
> HPD Software Limited or its affiliates.
> 
>