Deadlocks in the XPM Preview database

Question

We're experiencing very slow and/or failing Session Previews. In the logs we can find the following information. (I've edited this heavily - the actual logging is much fuller.)

[7/30/15 15:21:30:992 CEST] 000000c1 filter        
    E com.ibm.ws.webcontainer.filter.FilterInstanceWrapper doFilter 
    SRVE8109W: Uncaught exception thrown by filter Page Content Filter: 
        com.tridion.storage.persistence.session.SessionHandlingException: 
    StorageException occurred while persisting PreviewSession: 
        Unable to persist data entity
    Caused by: javax.persistence.PersistenceException: 
        org.hibernate.exception.LockAcquisitionException: 
    Transaction (Process ID 96) was deadlocked on lock resources with another process 
        and has been chosen as the deadlock victim. Rerun the transaction.

[7/30/15 15:21:30:994 CEST] 000000c1 webapp        
    E com.ibm.ws.webcontainer.webapp.WebApp logServletError 
    SRVE0293E: [Servlet Error]-[Static File wrapper]: 
        com.tridion.storage.persistence.session.SessionHandlingException: 
    StorageException occurred while persisting PreviewSession: 
        Unable to persist data entity
    Caused by: javax.persistence.PersistenceException: 
        org.hibernate.exception.LockAcquisitionException: 
    Transaction (Process ID 96) was deadlocked on lock resources with another process 
        and has been chosen as the deadlock victim. Rerun the transaction.

What can be causing the deadlocks? Is it possible that the filter and the rest of the web app are fighting each other? This is occurring when I am the only user on the system, so I don't think it's about multiple users conflicting with each other.

The web application is running on Websphere and the database is MSSQL. The preview web service is running on IIS.

Answer 1

So far, I have seen this occur once. It could be that the session preview data is not being cleaned up when the session expires, causing these deadlocks to happen. What I have understood is that, although that message is being logged is that it shouldn't have an impact on the performance of the Session Preview. I have also seen that that issue would go away if the user creates a new Session Preview db.