How to solve this error

  • Hi,

    I have developed a windows application in C#.net, In which billing has been performed at 4 billing windows and these computers are using indivisual software and connected with sql server installed on server by the lan network. But some time during billing I am face an error message i. e.

    "Transection (ProcessID 54) was deadlocked on lock resources with another Process and has been chosen as the deadlock victim return the transaction"

    Can any one tell me why this error occured and how can fix this error. Because this error never occured my side while I am checkhing it in debug mode. So please tell me how to resolve this Issue. Because of this issue peformance of my software is got poor.

  • This error is caused by two (or more) concurrent processes trying to acess/modify the same data and waiting for each other to finish.

    A more detailed description can be found at MSDN.

    Troubleshooting deadlocks is not really an easy task (at least most of the time). A good start to better understand the subject could be Barts article



    Lutz
    A pessimist is an optimist with experience.

    How to get fast answers to your question[/url]
    How to post performance related questions[/url]
    Links for Tally Table [/url] , Cross Tabs [/url] and Dynamic Cross Tabs [/url], Delimited Split Function[/url]

  • Hi,

    Perhaps some of your queries making lock on table.

    Run SP_LOCK and check lock status of your database.

    Run SQL Profiler and enable 1222 deadlock trace.

    Shatrughna

  • LutzM (9/17/2011)


    This error is caused by two (or more) concurrent processes trying to acess/modify the same data and waiting for each other to finish.

    A more detailed description can be found at MSDN.

    Troubleshooting deadlocks is not really an easy task (at least most of the time). A good start to better understand the subject could be Barts article

    There can be many things making this a problem for you, bu the basic problem is that you've created 2 (or more) processes working concurrently on the same set of data but they both have different methods of accessing that set of data.

    A very simplified example: processes A and B both need objects X and Y to do their job. Process A first works on object X, then to work on object Y. Process B first works on Y then on X. If the both processes need a transaction on their operations (i.e. X should only be modified if also Y is modified and vice versa), building the both processes to work as described can easily lead to dead locks. The way to fix this would be to either a) change the order of one of the processes or b) if you can't change the order, make sure that if either is currently working the other needs to wait until the first is completely done.

    That said, most of the times even with processes concurrently doing it "the wrong way", normally you will hardly ever encounter a dead lock: transactions are normally so short that hardly ever the processes are truly working concurrently. If you get this problem with only 4 end-users, you've probably not kept your transactions short enough. Most likely you have begun up a transaction and then let the end-user do some actions (may be just a message box saying: press 'OK') and then commit the transaction. This is a common beginners error: you should never, ever leave a transaction open and then give control to the end-user. Instead, ask the end-user for confirmation before you begin the transaction and do the action immediately followed by the commit (or rollback in case of an error).



    Posting Data Etiquette - Jeff Moden[/url]
    Posting Performance Based Questions - Gail Shaw[/url]
    Hidden RBAR - Jeff Moden[/url]
    Cross Tabs and Pivots - Jeff Moden[/url]
    Catch-all queries - Gail Shaw[/url]


    If you don't have time to do it right, when will you have time to do it over?

  • shatrughna (9/17/2011)


    Hi,

    Perhaps some of your queries making lock on table.

    Run SP_LOCK and check lock status of your database.

    Cant be sure that entire table is locked. It can even be a row/key lock.

    And locking is the mechanism used by all RDBMSs to ensure database consistency. Locking granularity depends on the amount of data requested/affected by the query (unless you give explicit lock hints).



    Pradeep Singh

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply