Skip to content

Add MongoDB's configuration properties for consistency#48879

Closed
jayychoi wants to merge 1 commit intospring-projects:mainfrom
jayychoi:add-mongodb-configuration-properties
Closed

Add MongoDB's configuration properties for consistency#48879
jayychoi wants to merge 1 commit intospring-projects:mainfrom
jayychoi:add-mongodb-configuration-properties

Conversation

@jayychoi
Copy link
Copy Markdown
Contributor

Related Issue

Closes gh-46261

Summary

This adds configuration properties for MongoDB's read and write consistency settings, enabling declarative configuration of ReadConcern, WriteConcern, and ReadPreference via application properties.

Currently, configuring MongoDB consistency settings requires either:

  • Using connection URI query parameters (e.g., ?readPreference=secondaryPreferred)
  • Implementing custom MongoClientSettingsBuilderCustomizer in Java

This approach lacks consistency with other properties and increases configuration complexity for operations teams. This enhancement allows configuration like:

spring:
  mongodb:
    read-concern: majority
    write-concern:
      w: majority
      journal: true
      w-timeout: 5s
    read-preference:
      mode: secondary
      tags:
        - region: east
          zone: primary
        - datacenter: A
      max-staleness: 90s

Changes

  • Added readConcern property to MongoProperties for read concern level configuration
  • Added WriteConcern nested class with w, journal, and wTimeout properties
  • Added ReadPreference nested class with mode, tags, and maxStaleness properties
  • Extended MongoConnectionDetails interface with getReadConcern(), getWriteConcern(), and getReadPreference() methods
  • Implemented conversion logic in PropertiesMongoConnectionDetails
  • Applied settings in StandardMongoClientSettingsBuilderCustomizer
  • Added comprehensive unit and integration tests

Design Decisions

  • New properties are applied after applyConnectionString(), so individual properties override URI settings.
  • The getters in PropertiesMongoConnectionDetails that create ReadConcern, WriteConcern, and ReadPreference objects were written with reference to the logic in ConnectionString that creates each object.
  • Validation throws InvalidConfigurationPropertyValueException when tags or max-staleness is configured without mode.
  • The read-preference.tags property support priority-based fallback using List<Map<String, String>> structure.
  • The read-preference.tags property can accept an empty map as the last fallback, which can be specified using - or - {} in YAML. This is not supported in application.properties due to format limitations.

Closes spring-projectsgh-46261

Signed-off-by: Jay Choi <jayyoungchoi22@gmail.com>
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Jan 18, 2026
* Read concern level for read operations. Supported values are 'local', 'available',
* 'majority', 'linearizable', and 'snapshot'. Overrides the value in 'uri' if set.
*/
private @Nullable String readConcern;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why it's not an enum?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for pointing that out. I was working with multiple properties and didn't think of it. I agree that using an enum would be better. In the same vein, I'm thinking of using an enum for ReadPreference.mode as well.

@wilkinsona
Copy link
Copy Markdown
Member

Thanks for the PR. It seems to ignore the ideas in #46261 (comment) without explaining why. It may be that those proposed properties are not adequate but we can't review this without an explanation of why that's the case.

@wilkinsona wilkinsona added the status: waiting-for-feedback We need additional information before we can continue label Jan 19, 2026
@jayychoi
Copy link
Copy Markdown
Contributor Author

@wilkinsona Sorry for not clarifying this upfront. If I missed anything else, please let me know.

Why spring.mongodb instead of spring.data.mongodb?

I noticed that the configuration previously under spring.data.mongodb was split into spring.data.mongodb and spring.mongodb in Spring Boot 4.0. So I considered which location would be more appropriate for these new properties. Since this issue was created before Spring Boot 4.0, it refers to spring.data.mongodb. However, I determined that these settings are for the MongoDB driver, not Spring Data, so I placed them under spring.mongodb.
Additionally, the existing property for configuring read/write consistency is spring.mongodb.uri, so it made sense to keep these properties in the same module.

Why were sub-properties added to write-concern?

You suggested using class constants for write concern configuration. However, this approach cannot configure journal and wtimeout for write concern. I believe these are important settings for MongoDB users. If these settings are not implemented as properties, users would have to use the URI or customize Java configuration to set journal and wtimeout, even though a write-concern property exists. This would reintroduce the exact problem that this issue aims to solve. Therefore, I included all necessary sub-properties (w, journal, w-timeout) to enable complete configuration of read/write consistency.

Why was name changed to mode for read preference?

The MongoDB official documentation uses the term "mode". I thought using the same terminology as the official documentation would be more intuitive for users.

@spring-projects-issues spring-projects-issues added status: feedback-provided Feedback has been provided and removed status: waiting-for-feedback We need additional information before we can continue labels Jan 19, 2026
@wilkinsona
Copy link
Copy Markdown
Member

Thanks for the additional details.

Using three separate properties to configure the write concern adds quite a bit of complexity for users. It means that they can't make use of the constants that, presumably, provide an easy way to use the most common configurations. That said, there may be some benefit to being able to configure a custom write concern that doesn't use one of the pre-canned constants. I'm not sure how best to do that using configuration properties. It may be that we only offer property-based configuration for the constants.

Unfortunately, having looked at this more, it's clear that we need to do some design work before any progress can be made here. Sorry for the wasted effort but I think we need to take a step back as it's not clear that this PR is heading in the right direction. Thanks anyway for the PR, but I'm going to close this one and label the issue as requiring design work.

@wilkinsona wilkinsona closed this Jan 19, 2026
@wilkinsona wilkinsona added status: declined A suggestion or change that we don't feel we should currently apply and removed status: feedback-provided Feedback has been provided status: waiting-for-triage An issue we've not yet triaged labels Jan 19, 2026
@jayychoi
Copy link
Copy Markdown
Contributor Author

Thanks for the review and feedback. I completely understand that design work needs to come first before implementation. Looking forward to contributing again once the direction is clearer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

status: declined A suggestion or change that we don't feel we should currently apply

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add configuration properties for MongoDB's read and write consistency

4 participants