Upgrade locking mechanism

Question

Upgrade locking mechanism

prolic opened this issue 7 years ago · 9 comments

Locking mechanism can be updated like in prolic/awesomeness. No lock-timeout is needed. Hopefully that's possible without BC.

Answer 1 · 2018-04-30T16:29:34.000Z

better to discuss this option in the correct issue:

@prolic changing the lock mechanism is a bc break. Isn't it?

Answer 2 · 2018-04-30T16:31:30.000Z

Not sure. From end user perspective nothing changes, only internals are affected.

…

On Tue, May 1, 2018, 00:29 Alexander Miertsch ***@***.***> wrote: better to discuss this option in the correct issue: @prolic <https://github.com/prolic> changing the lock mechanism is a bc break. Isn't it? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#145 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAYEvEgOIStSernuk0KZxStFZhi-s2zWks5ttzvugaJpZM4Tr9cw> .

Answer 3 · 2018-04-30T16:32:15.000Z

Also what happens if lock cannot be released? Throwing an exception might not be a good solution. You end up in a deadlock, right?

With the current solution another projection process can take over when lock timeout is reached.

Not sure. From end user perspective nothing changes, only internals are
affected.

But db schema changes

Answer 4 · 2018-04-30T16:36:16.000Z

If connection is closed, lock is gone immediately. Nothing to worry. New schema would not have lock_until column, existing columns just stay, they are not a problem.

…

On Tue, May 1, 2018, 00:32 Alexander Miertsch ***@***.***> wrote: Also what happens if lock cannot be released? Throwing an exception might not be a good solution. You end up in a deadlock, right? With the current solution another projection process can take over when lock timeout is reached. Not sure. From end user perspective nothing changes, only internals are affected. But db schema changes — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#145 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAYEvGENrCZV33ON_ZtwHc-42O2fSxLdks5ttzyPgaJpZM4Tr9cw> .

Answer 5 · 2018-04-30T16:38:48.000Z

ok sounds good, but I'm not a database expert. Not sure if we can change behavior without some stress tests ...

Answer 6 · 2018-04-30T21:04:10.000Z

We can create an experimental feature branch and ask a few people if they can test the modified projection lock mechanism in their projects. If we get positive feedback, I'm ok with it

Answer 7 · 2018-04-30T21:23:27.000Z

According to documentation this does not work with statement-based replication (which usually is the default).
Also, the timeout probably should not be infitinte. This is not the time how long the lock is helt but how long it is waited for to get aquired. Having this infite would change behavior that processes unable to aquire the lock fail-exit but wait indefinitely for the lock to become available now. Having a timeout of 0 instead would result in the current behavior of failing right away if the lock could not get aquired.

Answer 8 · 2018-05-01T10:36:49.000Z

binlog_format default value is ROW. But we can add another hint in the documentation, that you should not change that.

The timeout should be 0, that's still a bug in prolic/awesomeness

Answer 9 · 2018-05-03T11:10:58.000Z

closing this now. reason: it's not possible to do without any BC breaks, I see any limitations on mysql server settings after the fact as a BC. This will only be changed in new major release.