Timeline for org.hibernate.ResourceClosedException: This TransactionCoordinator has been closed
Current License: CC BY-SA 3.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 27, 2015 at 17:12 | vote | accept | ToddB | ||
| Jan 26, 2015 at 21:55 | comment | added | Raimond | How many Workers do you have in your deployer config? Please try to isolate the DB transactions in the way Bjorn is describing. It seems like you're overloading the DB with a lot of writes which don't get committed in time. | |
| Jan 26, 2015 at 19:59 | history | edited | Nickoli Roussakov | CC BY-SA 3.0 |
added 33 characters in body
|
| Jan 25, 2015 at 2:28 | history | tweeted | twitter.com/#!/StackTridion/status/559175846989422594 | ||
| Jan 24, 2015 at 15:39 | answer | added | Bjørn van Dommelen | timeline score: 3 | |
| Jan 23, 2015 at 18:43 | comment | added | ToddB | Thanks @Raimond. I just added an update 2 with more log data I have found. I have storing bindary data in the DB and verify the deployer is set to the right database. Also this we ran a database reindex and purge of publishing. | |
| Jan 23, 2015 at 18:33 | history | edited | ToddB | CC BY-SA 3.0 |
added 665 characters in body
|
| Jan 23, 2015 at 11:27 | comment | added | Raimond | "DEBUG PreCommitPhase - Executing worker com.tridion.storage.deploy.workers.BinaryWorker@7dc98e93 on transaction: tcm:0-16605-66560 this is worker 135 of: 2226 2015-01-21 19:01:24,075 WARN PreCommitPhase - Unable to store item inside current transaction: Unable to persist data entity" - It may be that your storage_conf is wrong in the place where it stores your binaries. If you store them in the DB - check your DB server logs. If you store them on the filesystem, check whether the paths are set correctly AND whether the deployer has sufficient access permissions. | |
| Jan 22, 2015 at 18:56 | history | edited | ToddB | CC BY-SA 3.0 |
added 824 characters in body
|
| Jan 22, 2015 at 18:31 | comment | added | Raimond | Note this line: "Failure in Phase: Deployment Prepare Commit Phase attempt: 11 for transaction: tcm:0-16605-66560". This means it's the 11th time the deployer tried to write something to storage. Usually the real error is only logged after the first attempt failed. Could you share that piece of log please? | |
| Jan 22, 2015 at 18:26 | answer | added | Rick Pannekoek | timeline score: 5 | |
| Jan 22, 2015 at 17:41 | comment | added | ToddB | Well good news it "should" be able to do this. @NunoLinhares I believe we are using transactional deployment as the logs are giving transaction IDs. How do I confirm though? | |
| Jan 22, 2015 at 17:35 | answer | added | Nickoli Roussakov | timeline score: 7 | |
| Jan 22, 2015 at 16:06 | history | edited | David Forster | CC BY-SA 3.0 |
Changing quote to code block for readability (line breaks mainly)
|
| Jan 22, 2015 at 15:58 | comment | added | Nuno Linhares♦ | I definitely agree with David's view - I saw performance problems on deploying 1000+ items, but not low hundreds. Are you using Transactional deployment? | |
| Jan 22, 2015 at 15:51 | comment | added | David Forster | 23 components / 93 items doesn't seem particularly large compared to some deployment packages I've seen before | |
| Jan 22, 2015 at 15:43 | history | asked | ToddB | CC BY-SA 3.0 |