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

Add declarative ClientSession support. [DATAMONGO-2093] #2962

Open
spring-projects-issues opened this issue Sep 20, 2018 · 3 comments
Open

Add declarative ClientSession support. [DATAMONGO-2093] #2962

spring-projects-issues opened this issue Sep 20, 2018 · 3 comments

Comments

@spring-projects-issues
Copy link

@spring-projects-issues spring-projects-issues commented Sep 20, 2018

Christoph Strobl opened DATAMONGO-2093 and commented

It should be possible to use MongoDB sessions and causal consistency model without transactions


1 votes, 3 watchers

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Sep 20, 2018

Nathaniel Mishkin commented

Is this a task you'd consider accepting implementation work from an outsider for? Is it plausible that someone whose interaction with Spring has primarily been as a consumer of its APIs and a browser of parts of its code base could make effective progress on this task? I.e., is motivation and willingness going to get me anywhere? :)

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Sep 20, 2018

Christoph Strobl commented

Nathaniel Mishkin contributions are always welcome, please make sure to follow the contribution guidelines. If this is you first contribution to one of the projects and you seek advise please let us know if the time allows us to we may be able to help you get started

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Sep 20, 2018

gburd commented

I see a clear use case for this feature.  It's perfectly reasonable to imagine a project starting with a single MongoDB instance (or even a simple, small replica set for disaster recovery or backup) inadvertently baking into their application logic a dependency on the implicit causal consistency provided by the single MongoDB instance.  Later there may be a need to "scale out" the application (move read traffic to replicas to scale writes at the master or geographically replicate data so as to avoid long distance requests when reading data) and change the read preference from PRIMARY to NEAREST (a "close" secondary replica) while still maintaining causal consistency guarantees to avoid having to rewrite the application to either a) deal with eventually consistent data or  b) employ a more strict transactional approach to data access.  In fact, I think this progression is more likely to be more common than starting with or transitioning to using transactions as that's a much newer feature than causal consistency in MongoDB.  Also, it seems to me that causal consistency can address a lot of the issues transactions are commonly used for without much of the associated overhead.

I'm glad to see this issue opened as it precludes the need to rewrite with a transactional model.  Also, I can't find a TransactionDefinition that maps to the particular guarantees provided by causal consistency

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants