Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO 4.1] : Reattachment issue with EOpposite
[CDO 4.1] : Reattachment issue with EOpposite [message #895887] Mon, 16 July 2012 12:43 Go to next message
Esteban Dugueperoux is currently offline Esteban DugueperouxFriend
Messages: 472
Registered: July 2009
Senior Member
Hi CDO Team,

We have a lock issue in one of our use cases, that I can explain using
the mode1.ecore example :

with 2 client sharing a model1.ecore based model with one Company owning
a Supplier and a PurchaseOrder, the Supplier referencing the PurchaseOrder,

The first client change the name of the Supplier and lock it (it doesn't
commit),
the second client clear the Company.purchaseOrders list and add yet the
PurchaseOrder then commit (theorically there is no change done by the
second client), the second client get the following exception on commit :

[ERROR] Rollback in MEMStore:
org.eclipse.net4j.util.concurrent.TimeoutRuntimeException: Could not
lock objects within 1000 milli seconds
at
org.eclipse.net4j.util.concurrent.RWOLockManager.wait(RWOLockManager.java:407)
at
org.eclipse.net4j.util.concurrent.RWOLockManager.lock2(RWOLockManager.java:89)
at
org.eclipse.emf.cdo.internal.server.TransactionCommitContext.lockObjects(TransactionCommitContext.java:804)

I have attached a JUnit test showing the issue, on the
Company.getPurchaseOrders().clear() I get a CDOSetFeatureDeltaImpl on
the opposite reference of PurchaseOrder (Supplier.purchaseOrders) and a
CDORemoveFeatureDeltaImpl on the Company.purchaseOrders reference.
On the company.getPurchaseOrders().add(purchaseOrder); I get a
CDOAddFeatureDeltaImpl on Company.purchaseOrders and a
CDOContainerFeatureDeltaImpl for the PurchaseOrder.eContainer java reference

Because of the ReattachTransition we shouldn't have changes before the
commit, right?

To explain our real use case, we use EMF Transaction with a pre-commit
(ResourceSetListenerImpl) to lock explicitly all changed objects, then
for client 1 we lock Supplier and for client 2 we lock the Company, but
like we have a Supplier as dirty objects on commit of client 2 we get
the previous exception.

It is a issue on the ReattachTransition or a bad use/understanding of CDO?

Best Regards.
Re: [CDO 4.1] : Reattachment issue with EOpposite [message #896060 is a reply to message #895887] Tue, 17 July 2012 06:26 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6441
Registered: July 2009
Senior Member
Hi Esteban,

After investigating for hours I'm now sure that there's a problem in CDO. Not in the locking mechanisms but in
CDOObjectImpl.adjustOppositeReference(), which is called during cdoInternalPostDetach(). Can you please submit a bugzilla?

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


Am 16.07.2012 14:43, schrieb Esteban Dugueperoux:
> Hi CDO Team,
>
> We have a lock issue in one of our use cases, that I can explain using the mode1.ecore example :
>
> with 2 client sharing a model1.ecore based model with one Company owning a Supplier and a PurchaseOrder, the Supplier
> referencing the PurchaseOrder,
>
> The first client change the name of the Supplier and lock it (it doesn't commit),
> the second client clear the Company.purchaseOrders list and add yet the PurchaseOrder then commit (theorically there
> is no change done by the second client), the second client get the following exception on commit :
>
> [ERROR] Rollback in MEMStore: org.eclipse.net4j.util.concurrent.TimeoutRuntimeException: Could not lock objects within
> 1000 milli seconds
> at org.eclipse.net4j.util.concurrent.RWOLockManager.wait(RWOLockManager.java:407)
> at org.eclipse.net4j.util.concurrent.RWOLockManager.lock2(RWOLockManager.java:89)
> at org.eclipse.emf.cdo.internal.server.TransactionCommitContext.lockObjects(TransactionCommitContext.java:804)
>
> I have attached a JUnit test showing the issue, on the Company.getPurchaseOrders().clear() I get a
> CDOSetFeatureDeltaImpl on the opposite reference of PurchaseOrder (Supplier.purchaseOrders) and a
> CDORemoveFeatureDeltaImpl on the Company.purchaseOrders reference.
> On the company.getPurchaseOrders().add(purchaseOrder); I get a CDOAddFeatureDeltaImpl on Company.purchaseOrders and a
> CDOContainerFeatureDeltaImpl for the PurchaseOrder.eContainer java reference
>
> Because of the ReattachTransition we shouldn't have changes before the commit, right?
>
> To explain our real use case, we use EMF Transaction with a pre-commit (ResourceSetListenerImpl) to lock explicitly
> all changed objects, then for client 1 we lock Supplier and for client 2 we lock the Company, but like we have a
> Supplier as dirty objects on commit of client 2 we get the previous exception.
>
> It is a issue on the ReattachTransition or a bad use/understanding of CDO?
>
> Best Regards.


Re: [CDO 4.1] : Reattachment issue with EOpposite [message #896090 is a reply to message #896060] Tue, 17 July 2012 08:48 Go to previous message
Esteban Dugueperoux is currently offline Esteban DugueperouxFriend
Messages: 472
Registered: July 2009
Senior Member
Hi,

I have created the https://bugs.eclipse.org/bugs/show_bug.cgi?id=385268

Thanks.


On 17/07/2012 08:26, Eike Stepper wrote:
> Hi Esteban,
>
> After investigating for hours I'm now sure that there's a problem in
> CDO. Not in the locking mechanisms but in
> CDOObjectImpl.adjustOppositeReference(), which is called during
> cdoInternalPostDetach(). Can you please submit a bugzilla?
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
> Am 16.07.2012 14:43, schrieb Esteban Dugueperoux:
>> Hi CDO Team,
>>
>> We have a lock issue in one of our use cases, that I can explain using
>> the mode1.ecore example :
>>
>> with 2 client sharing a model1.ecore based model with one Company
>> owning a Supplier and a PurchaseOrder, the Supplier referencing the
>> PurchaseOrder,
>>
>> The first client change the name of the Supplier and lock it (it
>> doesn't commit),
>> the second client clear the Company.purchaseOrders list and add yet
>> the PurchaseOrder then commit (theorically there is no change done by
>> the second client), the second client get the following exception on
>> commit :
>>
>> [ERROR] Rollback in MEMStore:
>> org.eclipse.net4j.util.concurrent.TimeoutRuntimeException: Could not
>> lock objects within 1000 milli seconds
>> at
>> org.eclipse.net4j.util.concurrent.RWOLockManager.wait(RWOLockManager.java:407)
>>
>> at
>> org.eclipse.net4j.util.concurrent.RWOLockManager.lock2(RWOLockManager.java:89)
>>
>> at
>> org.eclipse.emf.cdo.internal.server.TransactionCommitContext.lockObjects(TransactionCommitContext.java:804)
>>
>>
>> I have attached a JUnit test showing the issue, on the
>> Company.getPurchaseOrders().clear() I get a CDOSetFeatureDeltaImpl on
>> the opposite reference of PurchaseOrder (Supplier.purchaseOrders) and
>> a CDORemoveFeatureDeltaImpl on the Company.purchaseOrders reference.
>> On the company.getPurchaseOrders().add(purchaseOrder); I get a
>> CDOAddFeatureDeltaImpl on Company.purchaseOrders and a
>> CDOContainerFeatureDeltaImpl for the PurchaseOrder.eContainer java
>> reference
>>
>> Because of the ReattachTransition we shouldn't have changes before the
>> commit, right?
>>
>> To explain our real use case, we use EMF Transaction with a pre-commit
>> (ResourceSetListenerImpl) to lock explicitly all changed objects, then
>> for client 1 we lock Supplier and for client 2 we lock the Company,
>> but like we have a Supplier as dirty objects on commit of client 2 we
>> get the previous exception.
>>
>> It is a issue on the ReattachTransition or a bad use/understanding of
>> CDO?
>>
>> Best Regards.
>
>
Previous Topic:creating a registry for objects with certain identifying features
Next Topic:CDO Hadoop
Goto Forum:
  


Current Time: Mon Aug 19 12:40:09 GMT 2019

Powered by FUDForum. Page generated in 0.01524 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top