Thanks for the reply! I can understand the situation with muti statement
transactions, but I'm not using transactions ( at least from my
perspective ); Im only issuing single 'atomic' statements. It would make
much more sense if mysql internally detected the deadlock, released the
locks and tried to process the statement again. It just seems so
counter-intuitive that i can connect, issue a single, isolated select
statement and get a deadlock. I dont know if this is possible, but I would
love something like this in the mysql engine:
retry-deadlock:
error = do_query();
if ( ( auto-commit == on ) && ( error == DEADLOCK ) && ( ++tries <
threshold ) ) {
warn('Deadlock detected. Retrying query.');
goto retry-deadlock;
}
Of course this could go into the application code, but it would have to go
around every single query, transactional or not, and that seems so
cumbersome given that the solution is the same in every case.
dpk
----- Original Message -----
From: "Michael Widenius" <[EMAIL PROTECTED]>
To: "Dana Powers" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, September 17, 2001 2:19 PM
Subject: Re: BDB table error
>
> Hi!
>
> >>>>> "Dana" == Dana Powers <[EMAIL PROTECTED]> writes:
>
> Dana> Certainly I understand how the deadlock can occur, but the question
is why
> Dana> is this acceptable behaviour? Is the application developer expected
to
> Dana> handle this case? If so, how? and shouldnt this be included in the
manual
> Dana> under BDB problems? If Im supposed to wrap _every_ sql call I make
to a BDB
> Dana> table with something like: 'do { query } while ( !deadlock );' why
would I
> Dana> even bother trying to use BDB tables? This seems to me like a
_fundamental_
> Dana> weakness of the BDB table type, and should at least be documented as
such...
>
> We shall will add som more documentation about this ASAP.
>
> In MySQL 3.23.43 you will get the following error:
>
> Error: 1213 (ER_LOCK_DEADLOCK)
> "Deadlock found when trying to get lock; Try restarting transaction",
>
> Anyway, the problem you are experiencing is something that is normal
> with all transactional databases. When you have many clients that is
> reading/updating the same table there is always cases when you will
> get deadlocks or other failure in the transaction and you have to redo
> the whole transaction in the application.
>
> Regards,
> Monty
>
> ---------------------------------------------------------------------
> Before posting, please check:
> http://www.mysql.com/manual.php (the manual)
> http://lists.mysql.com/ (the list archive)
>
> To request this thread, e-mail [EMAIL PROTECTED]
> To unsubscribe, e-mail <[EMAIL PROTECTED]>
>
>
>
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
