3

We are using Tridion 2013 SP1 and implemented Web Deployer. But when we try to publish full web site we get very frequently following error. Unable to get the root cause of the same and resolve. Please suggest. 

ERROR DeployPipelineExecutor - Unable to start processing deployment package with transactionId: tcm:0-1120538-66560
com.tridion.deployer.ProcessingException: Phase: Deployment Prepare Commit Phase failed. 
Unable to prepare transaction: tcm:0-1120538-66560
    at com.tridion.deployer.phases.DeployPipelineExecutor.runMainExecutePhase(DeployPipelineExecutor.java:209) [cd_deployer.jar:na]
    at com.tridion.deployer.phases.DeployPipelineExecutor.doExecute(DeployPipelineExecutor.java:100) [cd_deployer.jar:na]
    at com.tridion.deployer.phases.DeployPipelineExecutor.execute(DeployPipelineExecutor.java:64) [cd_deployer.jar:na]
    at com.tridion.deployer.TransactionManager.handleDeployPackage(TransactionManager.java:82) [cd_deployer.jar:na]
    at com.tridion.deployer.queue.QueueLocationHandler$1.run(QueueLocationHandler.java:180) [cd_deployer.jar:na]
    at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) [na:1.7.0_60]
    at java.util.concurrent.FutureTask.run(Unknown Source) [na:1.7.0_60]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [na:1.7.0_60]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [na:1.7.0_60]
    at java.lang.Thread.run(Unknown Source) [na:1.7.0_60]
Caused by: javax.persistence.OptimisticLockException: org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1
    at org.hibernate.ejb.AbstractEntityManagerImpl.wrapStaleStateException(AbstractEntityManagerImpl.java:1402) ~[hibernate-entitymanager.jar:4.0.1.Final]
    at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1308) ~[hibernate-entitymanager.jar:4.0.1.Final]
    at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1289) ~[hibernate-entitymanager.jar:4.0.1.Final]
    at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:261) ~[hibernate-entitymanager.jar:4.0.1.Final]
    at com.tridion.storage.persistence.JPABaseDAO.executeQueryListResult(JPABaseDAO.java:281) ~[cd_datalayer.jar:na]
    at com.tridion.storage.persistence.JPABaseDAO.executeQueryListResult(JPABaseDAO.java:249) ~[cd_datalayer.jar:na]
    at com.tridion.storage.persistence.JPABaseDAO.executeQueryListResult(JPABaseDAO.java:220) ~[cd_datalayer.jar:na]
    at com.tridion.storage.persistence.JPATaxonomyDAO.findTaxonomyKeyword(JPATaxonomyDAO.java:157) ~[cd_datalayer.jar:na]
    at com.tridion.storage.services.TaxonomyCounterService.updateKeywordReferenceCount(TaxonomyCounterService.java:66) ~[cd_datalayer.jar:na]
    at com.tridion.storage.services.TaxonomyCounterService.updateKeywordReferenceCount(TaxonomyCounterService.java:86) ~[cd_datalayer.jar:na]
    at com.tridion.storage.services.TaxonomyCounterService.updateKeywordsReferenceCount(TaxonomyCounterService.java:49) ~[cd_datalayer.jar:na]
    at com.tridion.storage.services.TaxonomyCounterService.updateKeywordsReferenceCount(TaxonomyCounterService.java:35) ~[cd_datalayer.jar:na]
    at com.tridion.storage.deploy.workers.PageWorker.doDeploy(PageWorker.java:78) ~[cd_datalayer.jar:na]
    at com.tridion.deployer.model.transaction.TransactionLogItemWorker.doWork(TransactionLogItemWorker.java:27) ~[cd_model.jar:na]
    at com.tridion.deployer.phases.PreCommitPhase.runPrepare(PreCommitPhase.java:155) ~[cd_deployer.jar:na]
    at com.tridion.deployer.phases.PreCommitPhase.execute(PreCommitPhase.java:101) ~[cd_deployer.jar:na]
    at com.tridion.deployer.phases.DeployPipelineExecutor.runMainExecutePhase(DeployPipelineExecutor.java:198) [cd_deployer.jar:na]
    ... 9 common frames omitted
Caused by: org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1
Improve this question

3 Answers 3

Reset to default
2

The log file is showing a OptimisticLockException so it might be related to: - the package(s) being published are quite large, making this a heavy transaction(s) on the broker database; - and each package might contain very similar content (i.e parent and children items)

I would check the numbers of workers set on the cd_deployer_conf.xml; the higher this value is, the more chance of concurrency issues you will have.

Improve this answer
5
  • Thanks Roli for the update. We have the folllowing settings WindowSize="10" Workers="5" Interval="20s". Please suggest what could be the best value here.
    – Tridion_Learner
    Commented Apr 2, 2015 at 13:37
  • Hi tridion_learner, the decrease of the number for workers will also depend on other factors that I am not yet aware of, such as: - the number of threads you currently have available on the Content Manager Server. - Do you have any advanced options enabled in the publishing dialog - Do you have a transaction timeout set in the cd_storage_conf.xml and if so, to how many minutes? - Do you have any database maintenance tasks (rebuild of indexes and update of statistics) in place for the broker database? - How many cpus on both the CM and CD servers?
    – Roli
    Commented Apr 2, 2015 at 15:02
  • Thanks Roli. Yes, we do have transaction timeout set in cd_storage_conf.xml file. Set values are MonitorInterval="5000" and Timeout="210000". We also have a database maintenance tasks (update of statistics) once in a week. We have 4 CPU servers.
    – Tridion_Learner
    Commented Apr 7, 2015 at 8:53
  • hi tridion_learner, i would start by increasing the transaction timeout in the cd_storage_conf.xml to something like 5 minutes. for my understanding, the 4 CPU server has both the CM and the CD running or are these separate servers? If the CM server has 4 CPU, the usual recommendation would be number of CPUs - 1 for the number of threads for rendering and for deploying (so in your case 3 threads for rendering and 3 for deploying). To change the deployer settings, please confirm the number of CPUs for the CD side.
    – Roli
    Commented Apr 7, 2015 at 11:18
  • We have segregated all the services in respective servers. for example we have separate Publisher, deployer, TCM server. All the server has 4 CPUs.
    – Tridion_Learner
    Commented Apr 7, 2015 at 12:03
0

It seems issues here is because of database user you specified in your storage config doesn't have proper access.

Try login with same user on your broker database and verify read/write access.

Also see here

Improve this answer
3
  • We checked the Login and its working fine. Also the said error we are not getting for all published items. Please suggest if anything else need to be checked.
    – Tridion_Learner
    Commented Apr 1, 2015 at 8:54
  • Try unpublishing and then re publishing again
    – vikas kumar
    Commented Apr 1, 2015 at 9:38
  • Here's a list I would check: - Network Service have permission to incoming folder - DB User have right permission - Is DB running out of space - Is cd_storage_conf configured correctly - JDBC driver there? - Correct Tridion dll/jar files - Tridion CD Hotfix
    – Robert Jin
    Commented Apr 1, 2015 at 16:27
0

We also faced the same issue then, The below reference helped us

https://stackoverflow.com/questions/14856708/attempting-to-deploy-a-binary-to-a-location-where-a-different-binary-is-already/14856967#14856967

along with that to find which component having same or duplicate name, with My DBA help I executed the below query.

SELECT * FROM BINARYVARIANTS where [path] like '%%'

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.