RE: innodb locking

2005-10-05 Thread Sujay Koduri
sujay -Original Message- From: Tony Leake [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 05, 2005 7:55 PM To: Sujay Koduri Cc: mysql@lists.mysql.com Subject: RE: innodb locking On Wed, 2005-10-05 at 07:12 -0700, Sujay Koduri wrote: > Is this happening every time you try this, or it

Re: innodb locking

2005-10-05 Thread Ian Sales (DBA)
Tony Leake wrote: Hi, I have a query: UPDATE dbseXyzOrders.tblOrder SET intPoUid = 98 WHERE intOrderUid = 10798 intOrderUid is the primary key There are 25 columns in the table and a further 8 of these have indexes on them. The table is innodb I have just tried to run the above query 3

Re: innodb locking

2005-10-05 Thread Ady Wicaksono
I have ever meet this problem, however i never found best solutions. Make sure that there're no other session that update the data with AUTOCOMMIT=0 If there's another session with autocommi=0 and update the data, kill it first so your session will not timeout lock use SHOW INNODB STATUS to s

RE: innodb locking

2005-10-05 Thread Tony Leake
On Wed, 2005-10-05 at 07:12 -0700, Sujay Koduri wrote: > Is this happening every time you try this, or it happened first time? It's not every time but this is not the first. Mostly the query is ok, but I would like to find out why it's happening. > Also can you please tell what isolation level ar

RE: innodb locking

2005-10-05 Thread Sujay Koduri
Is this happening every time you try this, or it happened first time? Yes you right that INNODB uses row level locks, and the only reason for that error should be that someone else is trying to update the same row. As we can see from the o/p of the show procee list, someone else is also trying to

Re: InnoDB locking 'non-existence' of a row

2004-01-21 Thread Heikki Tuuri
Alex, - Original Message - From: ""Zeltser, Alex"" <[EMAIL PROTECTED]> Newsgroups: mailing.database.myodbc Sent: Wednesday, January 21, 2004 10:28 PM Subject: RE: InnoDB locking 'non-existence' of a row > Hello Heikki, > > Thank you for y

RE: InnoDB locking 'non-existence' of a row

2004-01-21 Thread Zeltser, Alex
, Alex Zeltser List: MySQL General Discussion < Previous MessageNext Message > From: Heikki Tuuri Date: January 21 2004 4:32am Subject: Re: InnoDB locking 'non-existence' of a row Alex, diagram: record1 'gap' record2 (User A holds a next-key

Re: InnoDB locking 'non-existence' of a row

2004-01-20 Thread Heikki Tuuri
Hot Backup - a hot backup tool for InnoDB which also backs up MyISAM tables Order MySQL technical support from https://order.mysql.com/ - Original Message - From: ""Zeltser, Alex"" <[EMAIL PROTECTED]> Newsgroups: mailing.database.myodbc Sent: Tuesday, January 20,

RE: InnoDB locking 'non-existence' of a row

2004-01-20 Thread Zeltser, Alex
iginal Message- From: Joe Shear [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 20, 2004 11:00 AM To: Zeltser, Alex Cc: [EMAIL PROTECTED] Subject: RE: InnoDB locking 'non-existence' of a row hi, Selecting a non-existent row won't acquire any locks that prevents inserts from hap

RE: InnoDB locking 'non-existence' of a row

2004-01-20 Thread Joe Shear
re any way to make the second session block when both it and the first one are > 'locking' > non-existence of a row? > > Thanks in advance, > > Alex > > -Original Message- > From: Chris Nolan [mailto:[EMAIL PROTECTED] > Sent: Friday, Janua

RE: InnoDB locking 'non-existence' of a row

2004-01-20 Thread Zeltser, Alex
day, January 16, 2004 4:55 PM To: Zeltser, Alex Cc: [EMAIL PROTECTED] Subject: Re: InnoDB locking 'non-existence' of a row Hi Alex! On Sat, 2004-01-17 at 05:50, Zeltser, Alex wrote: > Hi, > > I wanted to take advantage of the InnoDB 'gap' locking to lock > '

Re: InnoDB locking 'non-existence' of a row

2004-01-16 Thread Chris Nolan
Hi Alex! On Sat, 2004-01-17 at 05:50, Zeltser, Alex wrote: > Hi, > > I wanted to take advantage of the InnoDB 'gap' locking to lock 'non-existence' of a > row, the way the > manual recommends. I tried to do this by using 'select ... for update', using the > 'mysql' client > from two separate s

Re: InnoDB locking: Different behavior on 3.23.55 and 4.0.13

2003-07-25 Thread Info
Estoy tomando el sol . q -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]

Re: InnoDB locking: Different behavior on 3.23.55 and 4.0.13

2003-07-25 Thread Info
Estoy tomando el sol . q -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]

Re: InnoDB locking: Different behavior on 3.23.55 and 4.0.13

2003-07-24 Thread Mikhail Entaltsev
m forwarding this to Sanja. IMHO current behaviour is absolutly correct. Mikhail. - Original Message - From: "Heikki Tuuri" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, July 24, 2003 11:43 PM Subject: Re: InnoDB locking: Different behavior on 3.23.55

Re: InnoDB locking: Different behavior on 3.23.55 and 4.0.13

2003-07-24 Thread Heikki Tuuri
Mikhail, I just tested this. You are probably using the query cache in 4.0. Then SELECT can return immediately without acquiring any locks. Of course, it can be discussed if the query cache, too, should respect LOCK TABLES. I am forwarding this to Sanja. Thank you, Heikki - Original Messag

Re: InnoDB Locking Problems

2002-08-09 Thread Mark Matthews
- Original Message - From: "Jeremy Zawodny" <[EMAIL PROTECTED]> To: "Joe Shear" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, August 09, 2002 5:27 PM Subject: Re: InnoDB Locking Problems > On Fri, Aug 09, 2002 at 02:38:03PM -0700,

Re: InnoDB Locking Problems

2002-08-09 Thread Joe Shear
yes, we are running at serializable, which also explains the locking problems, especially since we just upgraded from .49. thanks joe On Fri, 2002-08-09 at 15:27, Jeremy Zawodny wrote: > On Fri, Aug 09, 2002 at 02:38:03PM -0700, Joe Shear wrote: > > [snip] > > > COMMIT > > we are using the high

Re: InnoDB Locking Problems

2002-08-09 Thread Jeremy Zawodny
On Fri, Aug 09, 2002 at 02:38:03PM -0700, Joe Shear wrote: [snip] > COMMIT > we are using the highest level of transactional security -- the term for > it eludes me at the moment. You mean the isolation level? Are you running at SERIALIZABLE rather than READ-COMMITTED? IF so, why? You will h