beyond the
MySQL offerings.
> -Original Message-
> From: walter harms [mailto:wha...@bfs.de]
> Sent: Monday, July 23, 2012 9:31 AM
> To: mysql@lists.mysql.com
> Subject: Re: restrict Connect Time
>
>
>
> Am 23.07.2012 17:38, schrieb Reindl Harald:
> >
> &g
t;>
>> The programms watch certain states in the database,
>> the connect automatic at db startup, disconnecting
>> is an error case.
>
> so why do you want to restrict connect time
> if this is a error-case for you?
>
no, this is a misunderstanding,
i want to
not very clear. You use connection pooling, right.
If the same session/thread is held for long time, it means the thread is
not getting closed even after doing its job, and adding to execution time.
On Mon, Jul 23, 2012 at 9:05 PM, walter harms wrote:
>
>
> Am 23.07.2012 16:58, schrieb Ananda Ku
ic at db startup, disconnecting
> is an error case.
so why do you want to restrict connect time
if this is a error-case for you?
signature.asc
Description: OpenPGP digital signature
Am 23.07.2012 16:58, schrieb Ananda Kumar:
> so. its more of inactive connections, right.
> What do you mean by NEVER LOGOUT
>
The programms watch certain states in the database,
the connect automatic at db startup, disconnecting
is an error case.
re,
wh
> On Mon, Jul 23, 2012 at 8:17 PM, w
so. its more of inactive connections, right.
What do you mean by NEVER LOGOUT
On Mon, Jul 23, 2012 at 8:17 PM, walter harms wrote:
>
>
> Am 23.07.2012 16:37, schrieb Ananda Kumar:
> > why dont u setup a staging env, which is very much similar to your
> > production and tune all long running sql
Am 23.07.2012 16:37, schrieb Ananda Kumar:
> why dont u setup a staging env, which is very much similar to your
> production and tune all long running sql
>
They are tuned and they are fast :) but the never logout and therefore
the time get accumulated.
re,
wh
> On Mon, Jul 23, 2012 at 8:02
why dont u setup a staging env, which is very much similar to your
production and tune all long running sql
On Mon, Jul 23, 2012 at 8:02 PM, walter harms wrote:
>
>
> Am 23.07.2012 16:10, schrieb Ananda Kumar:
> > you can check the slow query log, this will give you all the sql's which
> > are t
Am 23.07.2012 16:10, schrieb Ananda Kumar:
> you can check the slow query log, this will give you all the sql's which
> are taking more time to execute
>
Yes but you will see the results only when the query is finished.
my first idea was to use something like this:
select * from information_sch
you can check the slow query log, this will give you all the sql's which
are taking more time to execute
On Mon, Jul 23, 2012 at 7:38 PM, walter harms wrote:
>
>
> Am 23.07.2012 15:47, schrieb Ananda Kumar:
> > you can set this is in application server.
> > You can also set this parameter in my.
Am 23.07.2012 15:47, schrieb Ananda Kumar:
> you can set this is in application server.
> You can also set this parameter in my.cnf
> wait_timeout=120 in seconds.
> But the above parameter is only for inactive session
>
acutualy i want to catch scripts running wild.
re,
wh
>
> On Mon, Jul
you can set this is in application server.
You can also set this parameter in my.cnf
wait_timeout=120 in seconds.
But the above parameter is only for inactive session
On Mon, Jul 23, 2012 at 6:18 PM, walter harms wrote:
> Hi list,
> is there a switch where i can restrict the connect/execution t
Hi list,
is there a switch where i can restrict the connect/execution time for a query ?
re,
wh
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql
13 matches
Mail list logo
