eksp event case.sql
[MDEV-33266] Undesired concurrent Event sessions Created: 2024-01-17 Updated: 2024-01-18 |
|
| Status: | Open |
| Project: | MariaDB Server |
| Component/s: | Documentation, Events |
| Fix Version/s: | N/A |
| Type: | Task | Priority: | Major |
| Reporter: | Tadas Balaišis | Assignee: | Ian Gilfillan |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Attachments: |
eksp event case.sql
|
| 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. |
| Comments |
| Comment by Sergei Golubchik [ 2024-01-17 ] | |||
|
This is intentional. We recommend that if you don't need concurrent execution, you use user-level locks, for example
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. | |||
| Comment by Sergei Golubchik [ 2024-01-17 ] | |||
|
But the documentation could spell this out explicitly. I couldn't find it in | |||
| Comment by Tadas Balaišis [ 2024-01-18 ] | |||
|
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. | |||
| Comment by Sergei Golubchik [ 2024-01-18 ] | |||
|
I agree, an additional option could solve it for users who want to disallow concurrent execution, while still allowing it, when needed |