Details

    Description

      Noticed undesired behaviour how event (CREATE EVENT) initiates executions. New session created despite the fact that previous call hasn't ended yet. This creates concurrency and locks.
      Would be nice to have option that new instance isn't started if previous call execution is still in action at scheduled time. As it works in Oracle jobs.

      Attachments

        Activity

          This is intentional. We recommend that if you don't need concurrent execution, you use user-level locks, for example

          IF GET_LOCK('my_event_lock_1', 2) THEN
             ...
          END IF;
          

          On the other hand, if MariaDB would automatically skip events because of concurrent execution, there would've been no way for a user to implement concurrent execution if needed.

          serg Sergei Golubchik added a comment - This is intentional. We recommend that if you don't need concurrent execution, you use user-level locks, for example IF GET_LOCK( 'my_event_lock_1' , 2) THEN ... END IF ; On the other hand, if MariaDB would automatically skip events because of concurrent execution, there would've been no way for a user to implement concurrent execution if needed.

          But the documentation could spell this out explicitly. I couldn't find it in

          serg Sergei Golubchik added a comment - But the documentation could spell this out explicitly. I couldn't find it in https://mariadb.com/kb/en/events/ https://mariadb.com/kb/en/event-limitations/ https://mariadb.com/kb/en/create-event/
          balta Tadas Balaišis added a comment - - edited

          Thank you for suggested idea to use GET_LOCK. That's acceptable. But it would be even better if additional option would be added to CREATE EVENT, ALTER EVENT commands, then there will be no need to implement locking for every single procedure called by each different event. So it becomes more like feature request now.

          balta Tadas Balaišis added a comment - - edited Thank you for suggested idea to use GET_LOCK. That's acceptable. But it would be even better if additional option would be added to CREATE EVENT, ALTER EVENT commands, then there will be no need to implement locking for every single procedure called by each different event. So it becomes more like feature request now.

          I agree, an additional option could solve it for users who want to disallow concurrent execution, while still allowing it, when needed

          serg Sergei Golubchik added a comment - I agree, an additional option could solve it for users who want to disallow concurrent execution, while still allowing it, when needed

          People

            Unassigned Unassigned
            balta Tadas Balaišis
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.