-
-
Notifications
You must be signed in to change notification settings - Fork 109
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
Cassandra: add locking to prevent concurrent migration execution #48
Comments
I'm a bit confused by the locking mechanism. I think it's a great feature, but the way it is implemented at the moment cannot be replicated in Cassandra since the fetch/release of the lock is done in a transactional manner. Locking in Cassandra would have been achieved by insert a row somewhere then deleting it when done, which is not possible with the current abstractions. |
Line 423 in 61c0e29
The See the |
OK. I'll start by removing the Lock function then. I'll see if I can have a way to implement I'll try to figure something out. |
You don't have to do anything with And if this function has to acquire a table level lock, I don't really see the problem (the naming perhaps ?). |
My bad, I meant The issue is that these methods are defined on the database, which doesn't know about schema (keyspace in Cassandra) nor table names; it's not like in SQL engines where there is a global lock mechanism. Or I fail to understand something, which is also entirely possible ;-) |
You are right. So it seems to have at least 2 ways of locking the database:
I know you can think of a beautiful abstraction @Pvlerick ;) |
For the design of the new locking strategy, as we face it, there are use cases where it makes sense to have that mecanism to the database and to the metadatatable level. So why don't we keep the 'old' design with the table Lock() method and change it a bit to have a bool TryLock() and a new bool TryReleaseLock() method ? For the Cassandra locking part, to allow strong consistency, maybe we need that the metadatable be in a keyspace with a replication factor of 1. It should be at least encouraged or even perhaps forced. What do you think @Pvlerick ? |
@lecaillon if I step back a little bit, the fundamental requirement is to avoid having two of the same Evolve migrations running at the same time. We define here "same Evolve migrations" by the fact that they use the same metadata table. The way this is achieved (ignoring Cassandra) is to use the locking mechanism provided by the different RDBMS (except SQLite that doesn't support it, I don't know much about it but I guess it's only ever used by one application so it is kind of pointless). If this locking is moved (conceptually) at the metadata table level, it would mean that it would then be coupled to the metadata table, which would theoretically allow two different Evolve migrations to run at the same time for as long as the don't use the same metadata table (it might sound like a weird weird scenario, but it might be the case for a large database that is used by multiple applications, which is bad design but not so uncommon; we have one at work). For RDBMS that provide a locking mechanism, this could simply be achieved by locking on the metadata tables's name while for Cassandra the plan is to use lightweight transactions which give strong consistency. Sorry, this is a bit longer that I intended, but I think in the end, your suggestion to have |
Always interresting ;) No, I meant use the TryAcquireApplicationLock AND the TryLock in the Evolve.cs WaitForApplicationLock() method. Depending the database only one locking method is implemented, the other one returns true. |
Ok, I'll try using what you included in the latest commits (cf8128c and up). I'm still wondering why we need to lock both at the application level and at the table level. Can't we just lock at the table level, conceptually, and use the advanced locking mechanisms of RDBMs that support is in there (such as |
@Pvlerick |
In fact only one strategy is defined by database. And I prefer the application level one when possible. Less prone to bug and more robust in my mind. |
@lecaillon ah, I see, I didn't think of the scenario indeed; it is true that the application level lock ensures that the schema creation is protected. This would be an issue in the case of the first call to Evolve. Regardless, the locking in Cassandra is now done, as soon as the master branch is stable I'll rebase on it and make a PR. I see that the error in Travis is from the Cassandra implementation, I'll have a look into it. |
@Pvlerick |
@Pvlerick |
Yes, I'm working on it. I'll add a commit to #50 to address that. |
All in the title. I'll add that ASAP.
The text was updated successfully, but these errors were encountered: