mongodb - Compare consistency models used in mgo -


mongodb servers queried multiple consistency rules. in mgo, setmode of session object changes consistency mode session. 3 types of consistency modes available: eventual, monotonic, , strong.

e.g.

session, err := mgo.dial("localhost") if err != nil {     panic(err) } defer session.close() //switch session monotonic behavior. session.setmode(mgo.monotonic, true)

i reading different consistency models in https://en.wikipedia.org/wiki/consistency_model

but relations between 3 models used in mgo?

is correct strong implies eventual, , eventual implies monotonic?

thanks.

these 3 consistency models mongodb claims support:

  • strong consistency: accesses seen parallel processes (or nodes, processors, etc.) in same order (sequentially).

  • monotonic reads: if process reads value of data item x, successive read operation on x process return same value or more recent value.

  • eventual consistency: if no new updates made given data item, accesses item return last updated value.

by these definitions, strong implies eventual, , strong implies monotonic, there no relation between eventual consistency , monotonic reads.

however, looking @ real system, there more found.

in mongodb, monotonic mode means client opens single connection secondary node. reads happen through connection. when write happens, client drops connection , connects primary node, , performs write. reads following write performed primary node.

in eventual mode, reads done multiple secondary nodes, concurrently. means might see updates out of order, reach different nodes. writes performed against primary, possibly in multiple concurrent connections. means writes may arrive out of order well. not clear documentation if reads following first write served primary, in monotonic mode, or if continue served secondaries. the source code, however, tells reads continue served secondaries. 

// switch on monotonic session master. if !slaveok && s.consistency == monotonic {     s.slaveok = false }

thus, mgo v2, strong implies monotonic implies eventual.


Comments

Post a Comment

Popular posts from this blog

jOOQ update returning clause with Oracle -

according http://www.jooq.org/doc/3.8/manual/sql-building/sql-statements/update-statement/ jooq doesn't support returning clause in update statements databases except firebird , postgres. does know, still correct oracle jooq? according oracle's documentation, oracle db supports returning clase delete, insert, or update statements. incorrect manual you're right - manual wrong , should fixed: https://github.com/jooq/jooq/issues/5470 single row update returning jooq 3.8 added support single row update .. returning statements. internally, uses callablestatement , pl/sql block of form: begin update "my_table" set "my_table"."column" = 'xyz' "my_table"."id" = 1 returning "my_table"."id", "my_table"."column" ?, ?; ? := sql%rowcount; end; the relevant issue is: https://github.com/jooq/jooq/issues/5190 multi row update returning a...
Read more

java - Warning equals/hashCode on @Data annotation lombok with inheritance -

i have entity inherits other. on other hand, i'm using lombok project reduce boilerplate code, put @data annotation. annotation @data inheritance produces next warning: generating equals/hashcode implementation without call superclass, though class not extend java.lang.object. if intentional, add '@equalsandhashcode(callsuper=false)' type. is advisable add annotation @equalsandhashcode (callsuper = true) or @equalsandhashcode (callsuper = false) ? if not added, 1 callsuper=false or callsuper=true ? the default value false . 1 if don't specify , ignore warning. yes, recommended add @equalsandhashcode annotation on @data annotated classes extend else object. cannot tell if need true or false , depends on class hierarchy, , need examined on case-by-case basis. however, project or package, can configure in lombok.config call super methods if not direct subclass of object. lombok.equalsandhashcode.callsuper = call for configuration system ...
Read more

java - BasicPathUsageException: Cannot join to attribute of basic type -

i using java 8 jpa (hibernate 5.2.1). have clause works perfectly, until introduce clause make use foreign key table values too. i getting following error: basicpathusageexception: cannot join attribute of basic type i think problem related fact have join table, , not sure how create join using join table. employee - employee_category - category model (employee.java): @manytomany(cascade = cascadetype.all, fetch=fetchtype.eager) @jointable ( name="employee_category", joincolumns={ @joincolumn(name="emp_id", referencedcolumnname="id") }, inversejoincolumns={ @joincolumn(name="cat_id", referencedcolumnname="id") } ) private set<category> categories; model (category.java): @id private string id; jpa when introduce following code, fails error above (i think problem new piece of code): join<t, category> category = from.join("id"); predicates.add(criteriabuilder.like(category....
Read more