Experience Manager Session Preview causes temporary files to be created for pages and binaries in my staging website (html pages published to Tomcat 7 - stuff like index_789816da-1614-403f-9538-879fd05b9c57.html). Some of these are more than two days old - how do these get cleaned up? I checked all the web app config files, but can't find any settings there, or by searching the online docs.

UPDATE: There are some messages in the cd_preview log:

DEBUG JPAPublicationMappingDAO - Retrieving PublicationMapping by mappingKey: ae553687-ecbd-4645-955b-6b7998c6d45d. 2013-11-21 10:15:03,401

DEBUG JPAItemDAO - Removing binary meta from storage 2013-11-21 10:15:03,405

ERROR SessionWrapperFactory - Exception while cleaning-up session data: Error while committing the transaction, Error while committing the transaction

  • I would think they get deleted automatically, but perhaps the file system permissions prevent it? Nov 21, 2013 at 10:50

1 Answer 1


There's a hotfix for that... (this is fixed in SP1).

If you're on SQL Server (I think with Oracle it is exactly the same fix), run this on the preview database:



Now that I think of it... run this on all your Content Delivery Databases...


Fixed with cumulative hotfix CD_2013.0.0.86156

  • Thanks Nuno - any idea of the official hotfix number (I cannot find it on sdltridionworld.com), so I can request it from CS and this can be "officially" applied - the databases are off limits for us CMS devs.
    – Will Price
    Nov 21, 2013 at 11:53
  • Hotfix only contains jars and no SQL. Its for: - TT84562 Undo transport package contains only one binary with VariantId - TT84847 Hanging threads in broker - TT85023 Error in Precommit phase if we deploy CustomMeta to FileSystem and one of the values is empty - TT85248 Wrong title of embedded binary in the ITEMS table after undo - TT85262 When we store page content on a filesystem we always capture it with UTF-8 chartset during undo capturing - TT86037 When attempting to deploy content, it fails with error: Unable to persist data entity, org.hibernate.exception.ConstraintViolationException
    – Will Price
    Nov 27, 2013 at 7:29
  • 1
    I am going to try it out anyway, as its got some other useful fixes in... will update shortly if it works or not
    – Will Price
    Nov 27, 2013 at 7:33
  • Yes, the SQL change was not needed, just another way of getting the same results...
    – Nuno Linhares
    Nov 27, 2013 at 10:32
  • Yes - the hotfix mentioned indeed fixes the problem
    – Will Price
    Feb 18, 2014 at 10:08

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.