- Original Message -
> From: "trimurthy"
>
> hi sir even i also have a doubt regarding the connections. suppose if
> there is an existing connection to the server with the user name
> "xxx" and password "" if i send another request with the same user name
> and password then what will
- Original Message -
> From: "Markus Falb"
>
> With a low timeout the connection will be terminated sooner, but if
> the application retries another connection is taken. I could have raised
> the timeout with the same effect on the db side (1 process is waiting)
> but maybe more performan
Am 12.10.2012 19:58, schrieb Hubert de Donnea:
> I get all your mails for yearscould you not help me and suppress my name
> from your contact
what the hell
why do people subscribe to a mailing-list without use
google to understand what a mailing-list is?
http://en.wikipedia.org/wiki/Mail
You are subscribed to the MySQL mailing list. You will need to unsubscribe
yourself.
On Fri, Oct 12, 2012 at 6:58 PM, Hubert de Donnea <
hubertdedon...@hotmail.com> wrote:
> I get all your mails for yearscould you not help me and suppress my
> name from your contact thanks
>
> > To: mysql@li
I get all your mails for yearscould you not help me and suppress my name
from your contact thanks
> To: mysql@lists.mysql.com
> From: markus.f...@fasel.at
> Subject: innodb_lock_wait_timeout and replication
> Date: Fri, 12 Oct 2012 16:08:42 +0200
>
> I encountered an error
> MySQL Error: Lo
In my implementation we found no need to establish a new connection after a
lock timeout but just retried on the existing connection. We did instigate
a sleep timeout of 10 ms which theoretically increased on each iteration
but we never had to try a third time even under very heavy load.
On 2012-1
Am 12.10.2012 15:39, schrieb Markus Falb:
> With a low timeout the connection will be terminated sooner, but if the
> application retries another connection is taken. I could have raised the
> timeout with the same effect on the db side (1 process is waiting) but
> maybe more performant (no new c
On 11.10.2012 14:43, Johan De Meersman wrote:
>
> - Original Message -
>> From: "Markus Falb"
>>
>> But why is retrying better than raising the value?
>>
>> So what is better, adjusting the timeout or retrying application side
>> and why?
>
> Well, raising the timeout would probably help
noDB tries to avoid _blocking_ other statements. (MyISAM tries much less
hard.)
> -Original Message-
> From: Michael Dykman [mailto:mdyk...@gmail.com]
> Sent: Thursday, October 11, 2012 10:00 AM
> To: MySQL
> Subject: Re: RE: innodb_lock_wait_timeout
>
> The origi
The original poster mentioned that he is not using transactions explicitly.
Some transactions may still occur as a side effect of some operations under
certain conditions and, in a busy high load environment, cannot be entirely
avoided. Having some experience with this, I can report that it is safe
m: Akshay Suryavanshi [mailto:akshay.suryavansh...@gmail.com]
> Sent: Thursday, October 11, 2012 8:31 AM
> To: Andrés Tello
> Cc: Johan De Meersman; Markus Falb; mysql@lists.mysql.com
> Subject: Re: innodb_lock_wait_timeout
>
> Hi,
>
> Check the transactions which are caus
Hi,
Check the transactions which are causing locks. Use show engine innodb
status \G to find out the transactions acquiring locks for so long. As the
scenario you mentioned (like you use innodb at simpler level), you might be
in a situation where there are SELECTs causing the issue.
It is strange
Are you managing transactions with mysql + innodb?
I had a similar issue, and I need to rework the application.
innodb does a row level transaction lock. Read locks aren't exclusive,
update locks are exclusive.
What I was doing was something like this:
Thread P1
begin;
innodb: update field set
On Thu, Oct 11, 2012 at 7:29 AM, Markus Falb wrote:
> Should I raise innodb_lock_wait_timeout? What are the disadvantages?
The disadvantage is that if the locks still don't clear by the time
the timeout is reached, you're just making the other process wait
longer before failing.
> Should I retry
- Original Message -
> From: "Markus Falb"
>
> But why is retrying better than raising the value?
>
> So what is better, adjusting the timeout or retrying application side
> and why?
Well, raising the timeout would probably help, but may cause more concurrent
connections to stay open
15 matches
Mail list logo
