Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(db) implement the db:cluster_mutex() utility #3685

Merged
merged 1 commit into from Aug 9, 2018

Conversation

Projects
None yet
3 participants
@thibaultcha
Copy link
Member

thibaultcha commented Aug 8, 2018

This function can be called to set a cluster-wide lock (via the
underlying DB, currently C* only) to execute some code in a
"cluster-wide mutex".

@thibaultcha thibaultcha force-pushed the feat/db-lock-cassandra branch from fa3b7a9 to 8f775c2 Aug 8, 2018

key text PRIMARY KEY,
owner text
) WITH default_time_to_live = %d
]], default_ttl)

This comment has been minimized.

Copy link
@Tieske

Tieske Aug 8, 2018

Member

Shouldn't the above be in a migration? Not as much for this instance as well as creating a precedent.

Unless the intent is to use this lock, during migrations?

This comment has been minimized.

Copy link
@thibaultcha

thibaultcha Aug 8, 2018

Author Member

Unless the intent is to use this lock, during migrations?

Yes indeed

ngx.thread.wait(t2)

assert.spy(cb2).was_called()
assert.spy(cb1).was_not_called()

This comment has been minimized.

Copy link
@hishamhm

hishamhm Aug 8, 2018

Member

since cb2 takes 0.2 to run and t1 waits 0.2 until it acquires, isn't there a chance we get unlucky in this test and t2 releases the lock before t1 tries to acquire? (in other words, shouldn't the sleep in cb2 be a little longer than t1 to be on the safe side, or am I misunderstanding the test?)

feat(db) implement the db:cluster_mutex() utility
This function can be called to set a cluster-wide lock (via the
underlying DB, currently C* only) to execute some code in a
"cluster-wide mutex".

Example usage in the tests.

@thibaultcha thibaultcha force-pushed the feat/db-lock-cassandra branch from 8f775c2 to ab1f678 Aug 8, 2018

@thibaultcha thibaultcha merged commit aaadad5 into next Aug 9, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@thibaultcha thibaultcha deleted the feat/db-lock-cassandra branch Aug 9, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.