Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 312446 - Primary key or index violation during processing ReplicateRunnable on RepositorySynchronizer
Summary: Primary key or index violation during processing ReplicateRunnable on Reposit...
Status: CLOSED WORKSFORME
Alias: None
Product: EMF
Classification: Modeling
Component: cdo.core (show other bugs)
Version: 3.0   Edit
Hardware: PC All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Eike Stepper CLA
QA Contact: Eike Stepper CLA
URL:
Whiteboard: offline-05
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-11 11:08 EDT by Erwin Betschart CLA
Modified: 2010-07-07 07:10 EDT (History)
2 users (show)

See Also:


Attachments
Debug screenshot (172.48 KB, image/png)
2010-05-11 11:11 EDT, Erwin Betschart CLA
no flags Details
Code places to inspect (3.63 KB, patch)
2010-06-24 15:28 EDT, Eike Stepper CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Erwin Betschart CLA 2010-05-11 11:08:25 EDT
Build Identifier: 3.0

From time to time the following exception is thrown:

!ENTRY org.eclipse.net4j.util 4 0 2010-05-05 10:03:24.278
!MESSAGE org.h2.jdbc.JdbcBatchUpdateException: Eindeutiger Index oder Primarschlüssel verletzt: BASE_WHITEPAGE_USERPREFERENCES_IDX0 ON PUBLIC.BASE_WHITEPAGE_USERPREFERENCES(CDO_ID, CDO_VERSION, CDO_BRANCH)
Unique index or primary key violation: BASE_WHITEPAGE_USERPREFERENCES_IDX0 ON PUBLIC.BASE_WHITEPAGE_USERPREFERENCES(CDO_ID, CDO_VERSION, CDO_BRANCH); SQL statement:
INSERT INTO base_whitepage_UserPreferences(cdo_id, cdo_version, cdo_branch, cdo_class, cdo_created, cdo_revised, cdo_resource, cdo_container, cdo_feature, version, workbenchLayout) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) [23001-117]
!STACK 0
org.eclipse.net4j.db.DBException: org.h2.jdbc.	 PUBLIC.BASE_WHITEPAGE_USERPREFERENCES(CDO_ID, CDO_VERSION, CDO_BRANCH)
Unique index or primary key violation: BASE_WHITEPAGE_USERPREFERENCES_IDX0 ON PUBLIC.BASE_WHITEPAGE_USERPREFERENCES(CDO_ID, CDO_VERSION, CDO_BRANCH); SQL statement:
INSERT INTO base_whitepage_UserPreferences(cdo_id, cdo_version, cdo_branch, cdo_class, cdo_created, cdo_revised, cdo_resource, cdo_container, cdo_feature, version, workbenchLayout) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) [23001-117]
	at org.eclipse.net4j.db.DBUtil.deserializeTable(DBUtil.java:704)
	at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.AbstractHorizontalMappingStrategy.rawImport(AbstractHorizontalMappingStrategy.java:167)
	at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.rawImport(DBStoreAccessor.java:857)
	at org.eclipse.emf.cdo.internal.server.syncing.SynchronizableRepository.replicateRaw(SynchronizableRepository.java:210)
	at org.eclipse.emf.cdo.internal.net4j.protocol.ReplicateRepositoryRawRequest.confirming(ReplicateRepositoryRawRequest.java:43)
	at org.eclipse.emf.cdo.internal.net4j.protocol.ReplicateRepositoryRawRequest.confirming(ReplicateRepositoryRawRequest.java:1)
	at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientRequest.confirming(CDOClientRequest.java:85)
	at org.eclipse.net4j.signal.RequestWithConfirmation.doExtendedInput(RequestWithConfirmation.java:123)
	at org.eclipse.net4j.signal.Signal.doInput(Signal.java:311)
	at org.eclipse.net4j.signal.RequestWithConfirmation.doExecute(RequestWithConfirmation.java:103)
	at org.eclipse.net4j.signal.SignalActor.execute(SignalActor.java:66)
	at org.eclipse.net4j.signal.Signal.runSync(Signal.java:238)
	at org.eclipse.net4j.signal.SignalProtocol.startSignal(SignalProtocol.java:428)
	at org.eclipse.net4j.signal.RequestWithConfirmation.doSend(RequestWithConfirmation.java:87)
	at org.eclipse.net4j.signal.RequestWithConfirmation.send(RequestWithConfirmation.java:73)
	at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientProtocol.send(CDOClientProtocol.java:359)
	at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientProtocol.replicateRepositoryRaw(CDOClientProtocol.java:310)
	at org.eclipse.emf.cdo.internal.server.syncing.RepositorySynchronizer$ReplicateRunnable.run(RepositorySynchronizer.java:391)
	at org.eclipse.net4j.util.concurrent.QueueRunner.work(QueueRunner.java:26)
	at org.eclipse.net4j.util.concurrent.QueueRunner.work(QueueRunner.java:1)
	at org.eclipse.net4j.util.concurrent.QueueWorker.work(QueueWorker.java:75)
	at org.eclipse.net4j.util.concurrent.Worker$WorkerThread.run(Worker.java:188)
Caused by: org.h2.jdbc.JdbcBatchUpdateException: Eindeutiger Index oder Primarschlüssel verletzt: BASE_WHITEPAGE_USERPREFERENCES_IDX0 ON PUBLIC.BASE_WHITEPAGE_USERPREFERENCES(CDO_ID, CDO_VERSION, CDO_BRANCH)
Unique index or primary key violation: BASE_WHITEPAGE_USERPREFERENCES_IDX0 ON PUBLIC.BASE_WHITEPAGE_USERPREFERENCES(CDO_ID, CDO_VERSION, CDO_BRANCH); SQL statement:
INSERT INTO base_whitepage_UserPreferences(cdo_id, cdo_version, cdo_branch, cdo_class, cdo_created, cdo_revised, cdo_resource, cdo_container, cdo_feature, version, workbenchLayout) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) [23001-117]
	at org.h2.jdbc.JdbcPreparedStatement.executeBatch(JdbcPreparedStatement.java:1069)
	at org.eclipse.net4j.db.DBUtil.deserializeTable(DBUtil.java:700)
	... 21 more

Have a look at the attached debug screenshot.

After this error the clone repository is broken.

Reproducible: Sometimes
Comment 1 Erwin Betschart CLA 2010-05-11 11:11:12 EDT
Created attachment 167940 [details]
Debug screenshot

A CommitRunnable has two identical changed objects. This causes the primary key violation on the H2 database.
Comment 2 Eike Stepper CLA 2010-05-20 06:58:50 EDT
Seems to be in ReplicateRunnable rather than in CommitRunnable.
Comment 3 Eike Stepper CLA 2010-05-20 07:23:10 EDT
Erwin, can you try to reproduce this issue in a test case?
Comment 4 Eike Stepper CLA 2010-05-20 07:50:31 EDT
I doubt that the screenshot relates to this bug. It rather seems to belong to the resolved bug 312404.
Comment 5 Eike Stepper CLA 2010-05-20 07:53:22 EDT
Looking once more, I think it *can* be related to this issue. But the original stack trace is different, i.e. related with ReplicateRunnables.

Can it really relate to both runnable types?? Hmm...
Comment 6 Eike Stepper CLA 2010-05-20 07:58:08 EDT
Erwin, in your client application, are you moving objects between external and internal (CDO) resources?
Comment 7 Erwin Betschart CLA 2010-05-20 10:55:10 EDT
(In reply to comment #3)
> Erwin, can you try to reproduce this issue in a test case?

Tried it but was not successful.
Comment 8 Erwin Betschart CLA 2010-05-20 10:56:42 EDT
(In reply to comment #5)
> Looking once more, I think it *can* be related to this issue. But the original
> stack trace is different, i.e. related with ReplicateRunnables.
> 
> Can it really relate to both runnable types?? Hmm...

Your are right the stacktrace and picture do not correlate.
I'll try to reproduce it again so that stack trace and debug picture matches.
Comment 9 Erwin Betschart CLA 2010-06-22 04:02:01 EDT
(In reply to comment #6)
> Erwin, in your client application, are you moving objects between external and
> internal (CDO) resources?

No.
Comment 10 Rolf Kistler CLA 2010-06-24 03:52:04 EDT
I added some log output;
looks like the 1st RevisionDelta is duplicated (confirms Erwins comment #1) and the 2nd one gets discarded:

on the backend (master repository):

TransactionCommitContext.postCommit() createCommitInfo.getChangedObjects():

{
CDORevisionDelta[OobNode@OID2555:0v5 --> [CDOFeatureDelta[null, CONTAINER, resource=NULL, container=OID1377, feature=-4], CDOFeatureDelta[name, SET, value=Test Admin 1]]], 
CDORevisionDelta[OobNode@OID1488:0v24 --> [CDOFeatureDelta[children, LIST, list=[CDOFeatureDelta[children, REMOVE, value=UNKNOWN, index=0]]]]], 
CDORevisionDelta[OobNode@OID1377:0v26 --> [CDOFeatureDelta[children, LIST, list=[CDOFeatureDelta[children, ADD, value=OID2555, index=0]]]]]
}



on the client:

RepositorySynchronizer.CommitRunnable.run() commitInfo.getChangedObjects():

[
CDORevisionDelta[OobNode@OID2555:0v5 --> [CDOFeatureDelta[null, CONTAINER, resource=NULL, container=OID1377, feature=-4], CDOFeatureDelta[name, SET, value=Test Admin 1]]], 
CDORevisionDelta[OobNode@OID2555:0v5 --> [CDOFeatureDelta[null, CONTAINER, resource=NULL, container=OID1377, feature=-4], CDOFeatureDelta[name, SET, value=Test Admin 1]]], 
CDORevisionDelta[OobNode@OID1377:0v26 --> [CDOFeatureDelta[children, LIST, list=[CDOFeatureDelta[children, ADD, value=OID2555, index=0]]]]]
]
Comment 11 Eike Stepper CLA 2010-06-24 15:28:13 EDT
Hi Rolf, from looking at the code I still  can't see how this duplication/replacement can happen ;-(

Can you try to check the "changed objects" at the beginning of this method:
CDODataOutputImpl.writeCDOChangeSetData(CDOChangeSetData)

And at the end of this method:
CDODataInputImpl.readCDOChangeSetData()

I think this method is also interesting:
TransactionCommitContext.createCommitData()

Maybe you have a chance to look into the array that backs the changed objects list. The best check would be to iterate over the IndexedList right after it was created. I'll attach a patch that shows you where to set breakpoints and inspect the data
Comment 12 Eike Stepper CLA 2010-06-24 15:28:43 EDT
Created attachment 172673 [details]
Code places to inspect
Comment 13 Eike Stepper CLA 2010-06-29 04:54:27 EDT
Rebasing all outstanding 3.0 problem reports to version 3.0.1
Comment 14 Eike Stepper CLA 2010-07-06 08:09:09 EDT
Thg has never been reproducible and the user has reported that it has not occured for a long period. Closing as WORKSFORME for now. Please reopen if you encounter the same issue again.
Comment 15 Eike Stepper CLA 2010-07-07 07:10:16 EDT
Fixing wrong bug version.