http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Rafal, You have control over that as a user, you can decide whatever to pass the same replication base whenever using the same user.http://ayende.com/157057/implications-of-design-decisions-read-striping#comment9http://ayende.com/157057/implications-of-design-decisions-read-striping#comment9Wed, 18 Jul 2012 06:14:11 GMTJoao, not everyone is doing blogs ;) This 'session consistency' is a very weak guarantee for web applications when subsequent requests are very likely to be served from different replicas. Also, this approach requires bidirectional replication with very low latency, which will likely cause problems. 'User session' consistency would be a much better guarantee (the same database handling all requests from an user/web client). For example, some load balancers use client IP address to direct that client's request to same web server.http://ayende.com/157057/implications-of-design-decisions-read-striping#comment8http://ayende.com/157057/implications-of-design-decisions-read-striping#comment8Tue, 17 Jul 2012 19:37:58 GMTOK, I read up a little on Monotonic writes and what the sentence means is that <i>programming against</i> systems without this guarantee is notoriously difficult.http://ayende.com/157057/implications-of-design-decisions-read-striping#comment7http://ayende.com/157057/implications-of-design-decisions-read-striping#comment7Tue, 17 Jul 2012 17:03:52 GMT"Systems that do not guarantee this level of consistency are notoriously hard to program." I am sure thart should say "Systems that guarantee this level of consistency are notoriously hard to program." ?http://ayende.com/157057/implications-of-design-decisions-read-striping#comment6http://ayende.com/157057/implications-of-design-decisions-read-striping#comment6Tue, 17 Jul 2012 16:47:41 GMTRafal, That would only be an issue if the user spent less time on the screen than it took for replication to occur. And even so, usually it isn't a big deal. We don't always see our comments on the blog post right after we make them.http://ayende.com/157057/implications-of-design-decisions-read-striping#comment5http://ayende.com/157057/implications-of-design-decisions-read-striping#comment5Tue, 17 Jul 2012 16:43:00 GMTThe Session is an object that you create in code. It lives until you dispose of it. Therefore, you have control over the duration of your "consistency".http://ayende.com/157057/implications-of-design-decisions-read-striping#comment4http://ayende.com/157057/implications-of-design-decisions-read-striping#comment4Tue, 17 Jul 2012 15:37:28 GMTbut if you have a session per http request then the next request from the same user is quite likely to go to another server, isn't it? And maybe there will be no 'kaboom' but the user will be quite surprised when he won't see the changes he has just made...http://ayende.com/157057/implications-of-design-decisions-read-striping#comment3http://ayende.com/157057/implications-of-design-decisions-read-striping#comment3Tue, 17 Jul 2012 11:31:06 GMTSimon, Session id comes from a simple int32 that gets incremented on every session. It is not a connection id. Writes usually goes to the master, always, and the way RavenDB works, you do all the reads up front, then do a single write.http://ayende.com/157057/implications-of-design-decisions-read-striping#comment2http://ayende.com/157057/implications-of-design-decisions-read-striping#comment2Tue, 17 Jul 2012 09:46:49 GMTSimple solutions are always the best. Where does the session number come from? Is that similar a connection ID? What about using a website to update/read data. i.e. Could a load balancer affect your session number, by spreading your access over two webservers?http://ayende.com/157057/implications-of-design-decisions-read-striping#comment1http://ayende.com/157057/implications-of-design-decisions-read-striping#comment1Tue, 17 Jul 2012 09:43:01 GMT