Announcement

Collapse
No announcement yet.

Large number of Database Deadlock errors using Channel Writter

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Large number of Database Deadlock errors using Channel Writter

    I am experiencing a high volume of Database deadlock errors on the the MIRTH Database.

    I am using SQL Server 2005 32bit on a Windows Server 2003R2 server.

    The server has 8 cores with 8GB of RAM.

    I traced the messages back to a particular channel that had a high message volume.

    The channel had a channel writer as the destination.

    When I changed it to a file writer and modified the receiving channel as a file reader the errors went away.

    Does anyone have any ideas or suggestions.


    ERROR 2010-09-03 10:38:56,714 [b85b33f6-5801-46a0-9786-3c173d5a5485_destination_1_connector.028f237d-b1d9-4ebb-a1b3-47485ad748f2.receiver.1] com.webreach.mirth.server.controllers.DefaultMessa geObjectController: Error updating message dc6cfe2a-d9c2-499c-aff6-60ab76f8ba90 status due to a database problem
    com.ibatis.common.jdbc.exception.NestedSQLExceptio n:
    --- The error occurred in sqlserver2005/sqlserver2005-message.xml.
    --- The error occurred while applying a parameter map.
    --- Check the Message.updateMessageStatus-InlineParameterMap.
    --- Check the statement (update failed).
    --- Cause: java.sql.SQLException: Transaction (Process ID 165) was deadlocked on lock | communication buffer resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
    Caused by: java.sql.SQLException: Transaction (Process ID 165) was deadlocked on lock | communication buffer resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
    at com.ibatis.sqlmap.engine.mapping.statement.General Statement.executeUpdate(GeneralStatement.java:91)
    at com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelega te.update(SqlMapExecutorDelegate.java:505)
    at com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.up date(SqlMapSessionImpl.java:90)
    at com.ibatis.sqlmap.engine.impl.SqlMapClientImpl.upd ate(SqlMapClientImpl.java:67)
    at com.webreach.mirth.server.controllers.DefaultMessa geObjectController.updateMessageStatus(DefaultMess ageObjectController.java:240)
    Tom Smith
    IT Director
    Triad Radiology Associates

  • #2
    I am seeing the same on a few of my LLP destination channels that I have enabled persistent queues.

    I see the errors but when I look under the covers, it looks like the message gets sent anyway.

    My $0.02,

    beefmon

    Comment


    • #3
      This did become more of an issue once I enabled persistent Queues. It does appear that the message is sent. My concern is more how this will affect overall performance of the system.
      Tom Smith
      IT Director
      Triad Radiology Associates

      Comment


      • #4
        Resolution

        I have found a resolution to this issue for myself using SQL Server 2005. None of the SELECT, INSERT, UPDATE, or DELETE statements uses any hinting and as such the database server stupidly chose to lock pages instead of rows.

        I have updated the statements and added hinting (attached). If someone sees any problems with this please let me know. So far our high volume server is handling the message volume beautifully without any lock contention issues. Wooha.

        This file is placed in <mirth-home>/conf/sqlserver2005/

        Thanks,
        Frans
        Attached Files
        Frans de Wet
        Uber Operations LLC

        Phone: (850) 445-7696

        Comment


        • #5
          Further performance improvement

          Our DBA's found out that the parameters to the insert/update/delete etc queries (especially on the message table) were coming across as nvarchar. The message table, ID column is set as varchar. The conversion and subsequent mismatch with index etc caused severe performance degrading.

          They changed the type of the ID column in the MESSAGE table from varchar to nvarchar.

          We experienced a 10 fold increase in throughput and performance. If not more ... ;-)

          Woooha!

          Frans
          Frans de Wet
          Uber Operations LLC

          Phone: (850) 445-7696

          Comment


          • #6
            Is still necessary?

            I noticed the ID still says varchar in my database. Is this really affect my performance? Anybody have any idea? I can't find an error attached to it.

            Comment

            Working...
            X