cancel
Showing results for 
Search instead for 
Did you mean: 

Deadlock victim found in last dump. This will cause next round of synchronization.

0 Kudos
4,081

Hi, We are getting below error on production during system initialize.

(0000009Z) [CatalogVersionSyncJob] Sync 'sync realcanMarketplaceProductCatalog:Staged->Online' (pk:8796095807988) configured 40 entries for job '0000009Z' (pk:8796105834997) schedule medias: 1 (0000009Z) [CatalogVersionSyncJob] Finished configuration in 0d 00h:00m:00s:472ms. (0000009Z) [CatalogVersionSyncJob] Starting synchronization ...

(0000009Z) [CatalogVersionSyncMaster] 1. pass, 28 (+28) of 40 items processed (70 %), 31.01 items/sec, 23 (+23, deadlocks:23) items dumped. (0000009Z) [CatalogVersionSyncMaster] 2. pass, 22 (+34) of 23 items processed (95 %), 99.71 items/sec, 2 (+2, deadlocks:2) items dumped. (0000009Z) [CatalogVersionSyncCronJob] comparing last dumps (23/8796212887582 vs 2/8796212985886) - this might take some time... (0000009Z) [CatalogVersionSyncCronJob] Deadlock victim found in last dump. This will cause next round of synchronization. (0000009Z) [CatalogVersionSyncMaster] 3. pass, 1 (+2) of 2 items processed (50 %), 34.48 items/sec, 2 (+2, deadlocks:2) items dumped. (0000009Z) [CatalogVersionSyncCronJob] comparing last dumps (2/8796212985886 vs 2/8796213084190) - this might take some time... (0000009Z) [CatalogVersionSyncCronJob] Deadlock victim found in last dump. This will cause next round of synchronization. (0000009Z) [CatalogVersionSyncMaster] 4. pass, 1 (+2) of 2 items processed (50 %), 33.90 items/sec, 2 (+2, deadlocks:2) items dumped. (0000009Z) [CatalogVersionSyncCronJob] comparing last dumps (2/8796213084190 vs 2/8796213182494) - this might take some time... (0000009Z) [CatalogVersionSyncCronJob] Deadlock victim found in last dump. This will cause next round of synchronization. (0000009Z) [CatalogVersionSyncMaster] 5. pass, 1 (+2) of 2 items processed (50 %), 39.22 items/sec, 2 (+2, deadlocks:2) items dumped. (0000009Z) [CatalogVersionSyncCronJob] comparing last dumps (2/8796213182494 vs 2/8796213280798) - this might take some time... (0000009Z) [CatalogVersionSyncCronJob] Deadlock victim found in last dump. This will cause next round of synchronization.

Hybris version:- 1808.2 marketplace Database :- Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production Oracle JDBC driver : ojdbc7.jar

Has anyone encountered it?

0 Kudos

I found a rule. If I delete the online version of the category and synchronize it again, I will not report Deadlock.

0 Kudos

change the "Last modification of source item" of itemSyncTimestamp to future time will solve this problem temporarily

Accepted Solutions (1)

Accepted Solutions (1)

0 Kudos

The deadlock problem was solved by downgrade the hybris version from 1808 to 6.7...

And also as I see that there are some other bugs for oracle, such as the following two class simply do not support oracle, the code actually writes this :

{B:" + ProductModel.SALEABLE + "}=false"

de.hybris.platform.marketplaceservices.dao.impl.DefaultMarketplaceProductDao; de.hybris.platform.marketplaceservices.dao.impl.DefaultMarketplaceCartEntryDao;

0 Kudos

actually change ojdbc7 to ojdbc6 will fix this problem. since oracle 11g recommend ojdbc6.

Answers (4)

Answers (4)

the root cause is the following error

de.hybris.platform.catalog.SynchronizationPersistenceException: de.hybris.platform.servicelayer.exceptions.ModelSavingException: item pk 8796094333072 was modified concurrently - expected database version 0 but got 1, expected blocked = false but got blocked = false, entity state = de.hybris.platform.directpersistence.impl.OptimisticLockingAndItemLockingResultCheck@3d702cbd

it will caused db rollback.

510|master|181117-14:20:31:574|6 ms|rollback| /ConnectionImpl:529:ConnectionImpl:505:Transaction:1095:Transaction:1088:Transaction:1073:Transaction:1024:Transaction:1235:Transaction:1202:Transaction:1157:ItemCopyCreator:394:ItemCopyCreator:245:GenericCatalogCopyContext:2320:CatalogVersionSyncCopyContext:533:GenericCatalogCopyContext:2245:CatalogVersionSyncWorker:188:CatalogVersionSyncWorker:159:CatalogVersionSyncWorker$1:122:CatalogVersionSyncMaster:307:CatalogVersionSyncWorker:95:Thread:745:RegistrableThread:144:CatalogVersionSyncWorkerThread:78:RegistrableThread:134:END /|

0 Kudos

510|master|181117-14:20:31:564|5 ms|statement|UPDATE cat2catrel SET hjmpTS=?,modifiedTS=?,SequenceNumber=? WHERE PK=? AND hjmpTS=? AND (sealed IS NULL OR sealed=? )|UPDATE cat2catrel SET hjmpTS=1,modifiedTS='2018-11-17 14:20:31.557',SequenceNumber=753142058 WHERE PK=8796094333072 AND hjmpTS=0 AND (sealed IS NULL OR sealed=0 )

This sql will run before sync every time.

phoude
Participant
0 Kudos

were you able to resolve this? I have the same issue

priyanka_gupta2692
Participant
0 Kudos

Yes, Solution for this issue is: Delete the above PK-8796094333072 from database. And run synch job again.

Another solution is to do FullCatalogSynch again. This issue will not come again. It will resolve automatically.

priyanka_gupta2692
Participant
0 Kudos

Sometimes, Deadlock issue comes when another synch job is in Running status. In this case, "System Error can come" or "Job will always in Running Status".

So, first need to be sure. No other synch job is in Running Status. If any job is in Running status then delete that job and Start again.

VinayKumarS
Active Contributor
0 Kudos

I dont know this issue gets fixed forever or not. But on production i am seeing this issue from hybris 5.3. It continuous. Earlier when i was working with hybris cloud when we get such issue. They simply used to restart the nodes one by one in rolling fashion. so that user will not be impacted and after restarting of the systems. They used to run the full synchronization. It used to be fixed.

Product team never get this issue. Becuase only on production with large amount of data with different combinations this issue get occurred.

0 Kudos

actually i only have 13 categories distributed in three levels.. and no products. it is very small amount of data.

0 Kudos

restart nodes is ok, but the initial data is not fully imported at that time. and if i run sync job again after restart, it will be got deadlock victim again..

VinayKumarS
Active Contributor
0 Kudos

restnd do the forceupdate while syncing the system.

0 Kudos

but it will caused deadlock again...

former_member537989
Contributor
0 Kudos

this "Deadlock victim" message is misleading, actual cause could be for example exception like “duplicate ID detected” which increases a counter for "Deadlock victims". So I suggest you to analysed the dump file of catalog synchronisation. The dump file is part of media files created by cronjob during an execution

0 Kudos

I have analysed the dump file, it seems the "documents" field of some category can not be sync, but actually that field is empty. and this problem is not stable, If I sync the first level category first, then sync the second level, it can be success, but if i initialize, it will be got the Deadlock victim error. And everything is ok in my local evn with mysql. and content catalog sync job also got this error continuously.