This slide reminds me of the cache coherence problem. Session state is a global abstraction, but if each web server has its own local implementation, problem of incoherence emerges. If we use a global session state, it's like we are using a shared cache, which solves the coherence problem but doesn't scale. So the solution in next slides use multiple databases to serve different kinds of requests, which is kind of like the NUMA system.
althalus
Does it make sense that we might be fine with a relaxed consistency cache model since every person's logging into the website should only be doing it from one computer. This would mean that the same session ID would never be read by 2 servers for the same website. And if it did, the earlier server could log out for that ID.
temmie
@althalus I'm not sure I understand your comment, but I don't think it's uncommon for a single session to use multiple servers of the same website--it just depends on how the website is designed.
I'm not sure how cache coherence (if that's what you're referring to?) relates to that.
monkeyking
RESTful web services are required to be stateless so they are suitable in this case.
doodooloo
I guess storing the session data in the DB also helps when we want to scale down the server (kill some of the servers), otherwise we will lose the session in the servers killed.
This slide reminds me of the cache coherence problem. Session state is a global abstraction, but if each web server has its own local implementation, problem of incoherence emerges. If we use a global session state, it's like we are using a shared cache, which solves the coherence problem but doesn't scale. So the solution in next slides use multiple databases to serve different kinds of requests, which is kind of like the NUMA system.
Does it make sense that we might be fine with a relaxed consistency cache model since every person's logging into the website should only be doing it from one computer. This would mean that the same session ID would never be read by 2 servers for the same website. And if it did, the earlier server could log out for that ID.
@althalus I'm not sure I understand your comment, but I don't think it's uncommon for a single session to use multiple servers of the same website--it just depends on how the website is designed.
I'm not sure how cache coherence (if that's what you're referring to?) relates to that.
RESTful web services are required to be stateless so they are suitable in this case.
I guess storing the session data in the DB also helps when we want to scale down the server (kill some of the servers), otherwise we will lose the session in the servers killed.