Register | Sign In


Understanding through Discussion


EvC Forum active members: 59 (9164 total)
5 online now:
Newest Member: ChatGPT
Post Volume: Total: 916,923 Year: 4,180/9,624 Month: 1,051/974 Week: 10/368 Day: 10/11 Hour: 1/2


Thread  Details

Email This Thread
Newer Topic | Older Topic
  
Author Topic:   NodeJS Discussion
Percy
Member
Posts: 22508
From: New Hampshire
Joined: 12-23-2000
Member Rating: 5.4


Message 16 of 17 (911217)
06-19-2023 9:06 AM
Reply to: Message 15 by PaulK
06-19-2023 12:05 AM


Re: Issues From StackOverflow Question
This is from 13 years ago at MySQL InnoDB Deadlocks and Duplicate key errors (1213, 1205, 1062)] and is hopefully no longer true, but this is the kind of thing I'm concerned about:
quote:
#1213 Deadlock found when trying to get lock error
InnoDB locks rows and starts transactions internally as needed.
From time to time, particularly when concurrent threads are hitting the same rows, you're going to experience a deadlock.
Deadlocks happen when two transactions wait on each other to acquire a lock. For example:
Tx 1: lock A, then B
Tx 2: lock B, then A
Because InnoDB starts transactions on the internally, you -are- going to experience deadlocks.
No way of escaping it.
Fortunately when deadlocks do happen with this error 1213, all you have to do is retry the query until it goes through.
Maybe what this says is only partially true, because it says that InnoDB "locks rows and starts transactions internally as needed," and it doesn't mention explicitly handling transactions with BEGIN/COMMIT.
I've highlighted the key portion. My view is that random deadlocks out of the blue shouldn't happen except when database code is thrown together willy-nilly with little design effort. In my code for EvC deadlocks never happen, and if I change over to InnoDB and transactions while maintaining my code structure it seems to me that they should still never happen.
But maybe when locks are at the row level instead of the table level they *can* happen in well designed code, but I can't come up with any examples where that might happen in an EvC context.
I like that with deadlock detection enabled that deadlocks are automatically detected and the smallest transaction rolled back, but a casual search didn't reveal how to restart the transaction. And the statement, "Normally, you must write your applications so that they are always prepared to re-issue a transaction if it gets rolled back because of a deadlock," is concerning.
I also looked up how to detect deadlocks. One page suggested using SHOW ENGINE INNODB STATUS. When? After every COMMIT? After an operation like writing a message to the database. Before exiting?
I could find no code example of deadlock detection followed by retry.
--Percy

This message is a reply to:
 Message 15 by PaulK, posted 06-19-2023 12:05 AM PaulK has replied

Replies to this message:
 Message 17 by PaulK, posted 06-19-2023 9:21 AM Percy has seen this message but not replied

  
PaulK
Member
Posts: 17828
Joined: 01-10-2003
Member Rating: 2.5


Message 17 of 17 (911218)
06-19-2023 9:21 AM
Reply to: Message 16 by Percy
06-19-2023 9:06 AM


Re: Issues From StackOverflow Question
I don’t know InnoDB and my database experience is from years ago.
However, that’s an error code, not a bug and retrying would solve it.
There’s a similar issue from 3 years ago on StackOverflow but it involves a trigger and comments suggest that the use of a non-default isolation level might be part of the problem.

This message is a reply to:
 Message 16 by Percy, posted 06-19-2023 9:06 AM Percy has seen this message but not replied

  
Newer Topic | Older Topic
Jump to:


Copyright 2001-2023 by EvC Forum, All Rights Reserved

™ Version 4.2
Innovative software from Qwixotic © 2024