The code turns autocommit on and off throughout the entire application....
for a users.
There are no explicit locks that we have found.
I'm going to test by changing the isolation level to READ COMMITTED. This
may be what I'm looking for.
----- Original Message -----
From: "Mauricio Pérez" <mauriciocperez@stripped>
To: <win32@stripped>
Sent: Thursday, February 24, 2005 7:29 AM
Subject: Re: Deadlock Issue
> The variable autocommit assigned in that way is only for each user,
> not for all. You must set autocommit in the config file of the server
> (for all connections).
> It's this a problem?
>
> Any other procedures on the same table?
> You use any explicit lock table?
>
> Activate the server variable 'Lock Wait Timeout'.
>
> Mauricio.
>
>
> On Wed, 23 Feb 2005 16:15:17 -0500, Melissa Dougherty
> <melissa@stripped> wrote:
>> We are having a deadlock issue with a MySQL database application. We
>> have
>> two different users running transactions against the same table (INNODB
>> table type). The first user issues a DELETE statement and the other user
>> issues an INSERT. I thought the DELETE would only issue a row level
>> lock,
>> however, it is locking the table. When the commit from user 1 does not
>> come
>> right away, this causes a problem... does anyone have any suggestions?
>>
>> User 1:
>>
>> set autocommit=0;
>>
>> begin;
>>
>> delete from trans where val='a2';
>>
>> .....(additional statement... INSERTs and/or UPDATEs)
>>
>> User 2:
>>
>> set autocommit=0;
>>
>> begin;
>>
>> insert into trans (val) values ("b4");
>>
>>
>>
>>
>> Melissa A Dougherty
>> --
>> MySQL Windows Mailing List
>> For list archives: http://lists.mysql.com/win32
>> To unsubscribe:
>> http://lists.mysql.com/win32?unsub=1
>>
>>
>
> --
> MySQL Windows Mailing List
> For list archives: http://lists.mysql.com/win32
> To unsubscribe: http://lists.mysql.com/win32?unsub=1
>
