[Maria-discuss] Frequently running Event overlapping itself
I have an issue where a fast triggering event, running every 30 seconds, is occasionally running multiple times without each finishing. This is causing duplicate data as things are marked done one at a time.
I am trying to figure a solution such that this event can only run singly, but what is the best way? DISABLE at start and ENABLE at end? Do SESSION variables work between event invocations?
Hi, Brian!
On Aug 16, Brian Evans wrote:
I have an issue where a fast triggering event, running every 30 seconds, is occasionally running multiple times without each finishing. This is causing duplicate data as things are marked done one at a time.
I am trying to figure a solution such that this event can only run singly, but what is the best way? DISABLE at start and ENABLE at end?
That would work, I suppose.
Alternatively you can use GET_LOCK to synchronize events.
Do SESSION variables work between event invocations?
I'm not sure I understand this. You mean user variables, like @foo? No, every invocation is executed as in a new connection (kind of, not really a new connection) and user variables dissapear at disconnect.
Regards, Sergei
On 8/17/2011 2:25 PM, Sergei Golubchik wrote:
Hi, Brian!
On Aug 16, Brian Evans wrote:
I have an issue where a fast triggering event, running every 30 seconds, is occasionally running multiple times without each finishing. This is causing duplicate data as things are marked done one at a time.
I am trying to figure a solution such that this event can only run singly, but what is the best way? DISABLE at start and ENABLE at end?
That would work, I suppose.
Alternatively you can use GET_LOCK to synchronize events.
Thank you Sergei, I didn't notice the *_LOCK functions before. I have implemented this.
Do SESSION variables work between event invocations?
I'm not sure I understand this. You mean user variables, like @foo? No, every invocation is executed as in a new connection (kind of, not really a new connection) and user variables dissapear at disconnect.
Yes, that was what I was describing. Your explanation was expected, but I was unsure.
Brian
participants (2)
-
Brian Evans -
Sergei Golubchik