| [CDO] CDOTransaction lifecycle, attempt to modify historical revision [message #985862] |
Fri, 16 November 2012 13:17  |
 Matt Mursko
Messages: 5
Registered: October 2012 |
Junior Member |
|
|
I am currently working on porting an existing EMF application to CDO, specifically, we are using CDOWorkspace for clients. Our current implementation uses a single CDOTransaction to support all of the editors and views in our application. For persistence, we've added a TransactionalEditingDomainListener to our TransactionalEditingDomain's Lifecycle. This listener is responsible for incrementally calling CDOTransaction.commit() upon close of every EMF Transaction. CDOWorkspace.checkin() is initiated by the user via a button push.
As such, it is possible to call CDOTransaction.commit() multiple times between requests for CDOWorkspace.checkin(). If the same object is modified multiple times between CDOWorkspace.checkin(), the revision number is incremented each time as expected.
The problem I am seeing is a ConcurrentModificationException upon the first CDOTransaction.commit() after a CDOWorkspace.checkin() of an object that previously had more than one revision committed. I've attached a unit test that illustrates the problem.
My question is whether our expectation to use a single CDOTransaction in this style is legitimate, and this is a valid bug; or are we violating some assumptions and should look in a different direction?
Side note: I have temporarily worked around this problem by deferring CDOTransaction.commit() until immediately prior to CDOWorkspace.checkin(). This ensures the multiple revisions of an object are not included in a CDOWorkspace.checkin().
Thanks in advance,
Matt
WorkspaceTest to illustrate possible bug:
@Requires(IRepositoryConfig.CAPABILITY_UUIDS)
public void testMultipleAddsReusingTransaction() throws Exception
{
InternalCDOWorkspace workspace = checkout("MAIN", CDOBranchPoint.UNSPECIFIED_DATE);
CDOTransaction transaction = workspace.openTransaction();
CDOResource resource = transaction.getResource(getResourcePath(RESOURCE));
Product1 product = null;
for (int i = 0; i < PRODUCTS; i++)
{
product = createProduct(i);
resource.getContents().add(product);
transaction.commit();
}
CDOCommitInfo info = workspace.checkin();
resource.getContents().add(createProduct(PRODUCTS));
/*
* The following line generates the ConcurrentModificationException:
*/
transaction.commit();
info = workspace.checkin();
}
Exception stacktrace:
[ERROR] Rollback in MEMStore: java.util.ConcurrentModificationException: Attempt by Transaction[1:1] to modify historical revision: _HOYrkS_sEeKIAtS-2U2oCA:0v6
at org.eclipse.emf.cdo.internal.server.TransactionCommitContext.isContainerLocked(TransactionCommitContext.java:915)
at org.eclipse.emf.cdo.internal.server.TransactionCommitContext.lockObjects(TransactionCommitContext.java:832)
at org.eclipse.emf.cdo.internal.server.TransactionCommitContext.write(TransactionCommitContext.java:511)
at org.eclipse.emf.cdo.spi.server.InternalCommitContext$1.runLoop(InternalCommitContext.java:46)
at org.eclipse.emf.cdo.spi.server.InternalCommitContext$1.runLoop(InternalCommitContext.java:1)
at org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(ProgressDistributor.java:96)
at org.eclipse.emf.cdo.internal.server.Repository.commitUnsynced(Repository.java:911)
at org.eclipse.emf.cdo.internal.server.Repository.commit(Repository.java:904)
at org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicatingCommit(CommitTransactionIndication.java:295)
at org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicating(CommitTransactionIndication.java:97)
at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerIndicationWithMonitoring.indicating(CDOServerIndicationWithMonitoring.java:109)
at org.eclipse.net4j.signal.IndicationWithMonitoring.indicating(IndicationWithMonitoring.java:86)
at org.eclipse.net4j.signal.IndicationWithResponse.doExtendedInput(IndicationWithResponse.java:92)
at org.eclipse.net4j.signal.Signal.doInput(Signal.java:328)
at org.eclipse.net4j.signal.IndicationWithResponse.execute(IndicationWithResponse.java:65)
at org.eclipse.net4j.signal.IndicationWithMonitoring.execute(IndicationWithMonitoring.java:65)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:253)
at org.eclipse.net4j.signal.Signal.run(Signal.java:149)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
|
|
|
| Re: [CDO] CDOTransaction lifecycle, attempt to modify historical revision [message #985920 is a reply to message #985862] |
Fri, 16 November 2012 16:49  |
|
Am 16.11.2012 14:17, schrieb Matt Mursko:
> I am currently working on porting an existing EMF application to CDO, specifically, we are using CDOWorkspace for
> clients. Our current implementation uses a single CDOTransaction to support all of the editors and views in our
> application. For persistence, we've added a TransactionalEditingDomainListener to our TransactionalEditingDomain's
> Lifecycle. This listener is responsible for incrementally calling CDOTransaction.commit() upon close of every EMF
> Transaction. CDOWorkspace.checkin() is initiated by the user via a button push.
>
> As such, it is possible to call CDOTransaction.commit() multiple times between requests for CDOWorkspace.checkin().
> If the same object is modified multiple times between CDOWorkspace.checkin(), the revision number is incremented each
> time as expected.
>
> The problem I am seeing is a ConcurrentModificationException upon the first CDOTransaction.commit() after a
> CDOWorkspace.checkin() of an object that previously had more than one revision committed. I've attached a unit test
> that illustrates the problem.
>
> My question is whether our expectation to use a single CDOTransaction in this style is legitimate, and this is a valid
> bug; or are we violating some assumptions and should look in a different direction?
This sounds like a bug in CDOWorkspaceImpl. Can you please submit a bugzilla and attach the test case there?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
> Side note: I have temporarily worked around this problem by deferring CDOTransaction.commit() until immediately prior
> to CDOWorkspace.checkin(). This ensures the multiple revisions of an object are not included in a
> CDOWorkspace.checkin().
>
> Thanks in advance,
> Matt
>
>
> WorkspaceTest to illustrate possible bug:
>
> @Requires(IRepositoryConfig.CAPABILITY_UUIDS)
> public void testMultipleAddsReusingTransaction() throws Exception
> {
> InternalCDOWorkspace workspace = checkout("MAIN", CDOBranchPoint.UNSPECIFIED_DATE);
>
> CDOTransaction transaction = workspace.openTransaction();
> CDOResource resource = transaction.getResource(getResourcePath(RESOURCE));
> Product1 product = null;
> for (int i = 0; i < PRODUCTS; i++)
> {
> product = createProduct(i);
> resource.getContents().add(product);
> transaction.commit();
> }
>
> CDOCommitInfo info = workspace.checkin();
>
> resource.getContents().add(createProduct(PRODUCTS));
>
> /*
> * The following line generates the ConcurrentModificationException:
> */
> transaction.commit();
>
> info = workspace.checkin();
> }
>
>
> Exception stacktrace:
>
> [ERROR] Rollback in MEMStore: java.util.ConcurrentModificationException: Attempt by Transaction[1:1] to modify
> historical revision: _HOYrkS_sEeKIAtS-2U2oCA:0v6
> at org.eclipse.emf.cdo.internal.server.TransactionCommitContext.isContainerLocked(TransactionCommitContext.java:915)
> at org.eclipse.emf.cdo.internal.server.TransactionCommitContext.lockObjects(TransactionCommitContext.java:832)
> at org.eclipse.emf.cdo.internal.server.TransactionCommitContext.write(TransactionCommitContext.java:511)
> at org.eclipse.emf.cdo.spi.server.InternalCommitContext$1.runLoop(InternalCommitContext.java:46)
> at org.eclipse.emf.cdo.spi.server.InternalCommitContext$1.runLoop(InternalCommitContext.java:1)
> at org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(ProgressDistributor.java:96)
> at org.eclipse.emf.cdo.internal.server.Repository.commitUnsynced(Repository.java:911)
> at org.eclipse.emf.cdo.internal.server.Repository.commit(Repository.java:904)
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicatingCommit(CommitTransactionIndication.java:295)
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicating(CommitTransactionIndication.java:97)
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerIndicationWithMonitoring.indicating(CDOServerIndicationWithMonitoring.java:109)
> at org.eclipse.net4j.signal.IndicationWithMonitoring.indicating(IndicationWithMonitoring.java:86)
> at org.eclipse.net4j.signal.IndicationWithResponse.doExtendedInput(IndicationWithResponse.java:92)
> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:328)
> at org.eclipse.net4j.signal.IndicationWithResponse.execute(IndicationWithResponse.java:65)
> at org.eclipse.net4j.signal.IndicationWithMonitoring.execute(IndicationWithMonitoring.java:65)
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:253)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
Powered by
FUDForum. Page generated in 0.02794 seconds
] 
Search
Help
Register
Login
Home
