Upgrade locking mechanism
prolic opened this issue · comments
Locking mechanism can be updated like in prolic/awesomeness. No lock-timeout is needed. Hopefully that's possible without BC.
better to discuss this option in the correct issue:
@prolic changing the lock mechanism is a bc break. Isn't it?
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
ok sounds good, but I'm not a database expert. Not sure if we can change behavior without some stress tests ...
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
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.
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
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.