MongoDB Implementation?

[mhsimkin]

Hi.

Do you know if anyone has built a MongoDB implementation?

Thanks

[madelson]

Currently there is no MongoDB implementation included in this library.

Looking at NuGet, there is at least one package available that does distributed locking with Mongo (https://www.nuget.org/packages/DistributedLock.Mongo/). That package has no relationship with this library and I have no experience with it so I can't speak to its features or quality but I would definitely recommend giving it a try if you're looking for a Mongo solution in the near-term.

I would definitely be open to adding a MongoDB implementation to this library in the future and I will use this issue to track that feature request. From some quick googling, there doesn't seem to be a "standard" pattern that people follow for locking in Mongo. https://github.com/square/mongo-lock built by Square (written in Go) offers a straightforward-looking approach and could be a good model.

If you would be interested in contributing an implementation to this library, let me know and we can discuss what the steps would look like. It is typically a good amount of work to build out a new provider from scratch.

[mhsimkin]

@madelson Thank you for the links. What I found interesting about this specific library was support for Azure, MySql, SQL Server, Local (File, Wait Handle), and Oracle. My employer uses all all of those and Mongo, and a few other NoSql stores.

I've spent the last two days, trying to get my head around how the library works, so I could implement a Mongo provider. Conceptually it all makes sense. Understanding the actual implementation is not going well. All the interfaces are a bit overwhelming.

When I dig into implementation specifics, I get total confused with all the interfaces and the use of internal classes. Having a reference implementation, even if it a duplicate of an existing one, that just uses the public interfaces/classes would make it easier to build a Mongo implementation.

Talking Mongo specific, depending upon the version of the server there are different ways to achieve the same result. Using a BSON document with a two phase approach works on all versions.

The collection for the locks would have a unique index on the lock name field. The document that represents the lock would have several fields including lock name, id, lock state, etc.

When a lock is requested I plan on inserting a document with the lock name, unique id and an initial state of "initializing". If successful, I can then finalize the lock by setting lock state to "acquired", duration to expiration, last renewal time and a few other fields.

If there is already a document for the lock, a duplicate key error will be thrown. Then I could figure out if the existing lock is valid or expired and handle appropriately.

I haven't come to a decision on whether to use a separate sweep task to manage lock expiration.

As for contributing, that might be an issue. I have certain constraints from my employer. We are not prevented from using Open Source, At the same time, code I develop as part of my job is not mine to contribute.

End result, I'm really interested in seeing a reference implementation that doesn't rely on internals.

Cheers.

[nickwilliams-codynamic]

@madelson is this still something you would consider accepting a contribution for? If so I believe I should be able to pull something together fairly quickly.

I think, other than the MongoDB API bits, the implementation should be fairly similar to the exiting azure one.

[madelson]

@nickwilliams-codynamic yes I'd love to have a contribution here. If you're interested, the place to start would be to do a brief writeup here covering a few things:

• Which primitives (lock, rw lock, semaphore) are we supporting? Has to be lock at minimum.
• What does the under-the-hood implementation strategy look like? Is there an established method or convention for doing this with MongoDB? If so, we should be compatible with that (e.g. Redis doesn't have locks out of the box but the Redlock algorithm acts as a sort of standard).
• What will the API surface area look like? Most of this should follow from the conventions set by the different implementations, but the constructors are different for each and a key decision point. What options we expose is another key decision point.
• Any upfront questions you have about preferred implementation/testing approach or how the existing stuff works (some parts are kind of complex): this is a good place to ask!

Let's get aligned on the above to minimize backtracking on the coding itself.