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  |
 Esteban Dugueperoux
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  |
|
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.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO 4.1] : Reattachment issue with EOpposite [message #896090 is a reply to message #896060] |
Tue, 17 July 2012 08:48 |
Esteban Dugueperoux
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.
>
>
|
|
|
Goto Forum:
Current Time: Wed Apr 24 21:56:33 GMT 2024
Powered by FUDForum. Page generated in 0.02782 seconds |
] 
Search
Help
Register
Login
Home
