Also from what I see now 1.7-snapshot also does not distribute SQL selects. This is quite problematic - with saving new records I can just do a retry if I get 0 record suring a select but what if I select an existing record that is being updated? Then I might get a stale local copy even though my synchronous save/update said it's ok. Is there no way to tell mitigate this eventual consistency problem?
Mateusz On Thursday, April 17, 2014 10:41:02 AM UTC+9, Mateusz Dymczyk wrote: > > Version: 1.6.4 > > Is there a possibility to look for documents with a particular field value > in a distributed fashion which would use the read quorum value? Currenly > I'm using a synchronized SQL command but they are using quorum type NONE > and the only thing I could come up with was to retry a few times. > > Use case: > 1) 3 DB servers, read/writeQuorum = 2 > 2) User saves via DB1 doc1 > 3) doc1 is saved localy on DB1 and replicated to DB2 and DB3 > 4) DB2 gets the request, saves it locally and replies to DB1 that it's all > OK > 5) DB1 finishes the operation as it got the reply from DB2, returns a > positive response to the user > 6) user thinks the document is saved, tries to use it sending some "key" > value (string that is part of the document) > 7) DB3 gets the above request, checks *only the local DB* and replies > with an empty list, even though the remaining DBs have it already > 8) DB3 is slow and it just now saves the document sent by DB1 (the one > that was queried above) > > So the only thing I can do now is retry a few times step 7, is there some > other way? > > I see that in 1.7 the SQL command quorum was changed to ALL, that is much > better but still not 100% what I'd like (I prefer the readQuorum rather > than all). > > Mateusz > -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
