Skip to content
New issue

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

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

Already on GitHub? # to your account

Add Write Concern Levels #12

Closed
prolic opened this issue Aug 18, 2015 · 4 comments
Closed

Add Write Concern Levels #12

prolic opened this issue Aug 18, 2015 · 4 comments
Assignees
Milestone

Comments

@prolic
Copy link
Member

prolic commented Aug 18, 2015

Currently we use acknowledged write concern, which does not confirm that the write operation has persisted to the disk system.

We could switch to journaled.
With a journaled write concern, the MongoDB acknowledges the write operation only after committing the data to the journal. This write concern ensures that MongoDB can recover the data following a shutdown or power interruption.

Additonally: We can ack for replica sets.
With replica acknowledged write concern, you can guarantee that the write operation propagates to additional members of the replica set (not only the primary server).

If we want to use replica acknowleged write concern, we could need additional options for the mongo adapter in the constructor (how many replicates and timeout).

For more information about this see:

http://docs.mongodb.org/v3.0/core/write-concern/
http://docs.mongodb.org/v3.0/core/replica-set-write-concern/

Imho the journaled acknowlegement makes sence, since we don't want to lose information when there is a server crash following microseconds after we persisted an event when it's not yet written to disk. But do we need to have acks for distributing them across replicas?

@codeliner
Copy link
Member

yeah, sounds like journaled is the best default. But would be great to allow the user to configure the writeConcern. Can we pass a WriteConcernOptions object as optional parameter to the constructor?
Supporting all options defined here: http://docs.mongodb.org/v3.0/reference/connection-string/#write-concern-options
In this case setting the WriteConcernOptions via a setter would also be ok because the adapter does not need them to function correctly.

Events are the only source of truth so I can imagine that some users want to use the replica set write concern.

@prolic prolic self-assigned this Aug 18, 2015
@prolic prolic added this to the 1.0 Release milestone Aug 18, 2015
@prolic
Copy link
Member Author

prolic commented Aug 18, 2015

I'll do this.

@prolic prolic changed the title Question: Write Concern Levels Add Write Concern Levels Aug 18, 2015
@prolic
Copy link
Member Author

prolic commented Aug 18, 2015

@codeliner
Copy link
Member

ah the user could also configure the \MongoClient before passing it to the adapter. But yeah, in this case we can not default to journaled so 👍 for adding the WriteConcernOptions.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants