L12 Session State and Distributation Strategies


Published on

One of the most critical design decisions on enterprise programming is where to keep the state. As we talked about in the lecture on Concurrency, session state is the state that is maintained between requests. A session starts when the user first hits the enterprise system, and lasts until the user signs out or times out. In this lecture we look at the session state and explore three design patterns on where to store the session state.

The second topic in this lecture is how to distribution the applications. The primary reason we want to do that is to get more performance and handle more load. Most enterprise applications have lots of users, some hundreds of thousands. The only way to cope with such load is to scale the application. Scalability is how much more load an application can take if more resources are added. We will look at two ways to scale, one is by load balancing and the other by clustering.

Video of this lecture are found here:

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

L12 Session State and Distributation Strategies

  1. 1. Lecture 13 Session State and Distribution Strategies
  2. 2. Session State
  3. 3. Reading  Fowler 6 – Session State  Fowler 17 – Session State Patterns
  4. 4. Agenda  Session State – Business transactions  Session State Patterns – Client Session State – Server Session State – Database Session State
  5. 5. Business Transactions  Transactions that expand more than one request – User is working with data before they are committed to the database • Example: User logs in, puts products in a shopping cart, buys, and logs out – Where do we keep the state between transactions?
  6. 6. State  Server with state vs. stateless server – Stateful server must keep the state between requests  Problem with stateful servers – Need more resources, limit scalability
  7. 7. Stateless Servers  Stateless servers scale much better  Use fewer resources  Example: – View book information – Each request is separate
  8. 8. Stateful Servers  Stateful servers are the norm  Not easy to get rid of them  Problem: they take resources and cause server affinity  Example: – 100 users make request every 10 second, each request takes 1 second – One stateful object per user – Object are Idle 90% of the time
  9. 9. Session State  State that is relevant to a session – State used in business transactions and belong to a specific client – Data structure belonging to a client – May not be consistent until they are persisted  Session is distinct from record data – Record data is a long-term persistent data in a database – Session state might en up as record data
  10. 10. EXCERISE Question: Where do you store the session?
  11. 11. Ways to Store Session State  We have three players – The client using a web browser – The Server running the web application and domain – The database storing all the data
  12. 12. Ways to Store Session State  Three basic choices – Client Session State (456) – Server Session State (458) – Database Session State (462)
  13. 13. Client Session State Store session state on the client  How It Works – Desktop applications can store the state in memory – Web solutions can store state in cookies, hide it in the web page, or use the URL – Data Transfer Object can be used – Session ID is the minimum client state – Works well with REST
  14. 14. Client Session State  When to Use It – Works well if server is stateless – Maximal clustering and failover resiliency  Drawbacks – Does not work well for large amount of data – Data gets lost if client crashes – Security issues
  15. 15. Server Session State Store session state on a server in a serialized form  How It Works – Session Objects – data structures on the server keyed to session Id  Format of data – Can be binary, objects or XML  Where to store session – Application server, file or local database
  16. 16. Server Session State  Specific Implementations – HttpSession – Stateful Session Beans – EJB  When to Use It – Simplicity, it is easy to store and receive data  Drawbacks – – – – Data can get lost if server goes down Clustering and session migration becomes difficult Space complexity (memory of server) Inactive sessions need to be cleaned up
  17. 17. Database Session State Store session data as committed data in the database  How It Works – Session State stored in the database – Can be stored as temporary data to distinguish from committed record data  Pending session data – Pending session data might violate integrity rules – Use of pending field or pending tables • When pending session data becomes record data it is save in the real tables
  18. 18. Database Session State  When to Use It – Improved scalability – easy to add servers – Works well in clusters – Data is persisted, even if data centre goes down  Drawbacks – Database becomes a bottleneck – Need of clean up procedure of pending data that did not become record data – user just left
  19. 19. What about dead sessions?  Client session – No our problem  Server session – Web servers will send inactive message upon timeout  Database session – Need to be clean up – Retention routines
  20. 20. Caching  Caching is temporary data that is kept in memory between requests for performance reasons – Not session data – Can be thrown away and retrieved any time  Saves the round-trip to the database  Can become stale or old and out-dated – Distributed caching is one way to solve that
  21. 21. Practical Example  Client session – For preferences, user selections  Server session – Used for browsing and caching – Logged in customer  Database – “Legal” session – Stored, tracked, need to survive between sessions
  22. 22. QUIZ We are building an application for processing development grants. The application is complicated and users can login any time and continue work on their application. What design pattern would we use for storing the session? A) B) ✔ C) D) Client Session State Server Session State Database Session State No state required
  23. 23. Distribution Strategies
  24. 24. Reading  Fowler 7 – Distribution Strategies  Fowler 15 – Distribution Patterns – Remote Façade (388)
  25. 25. Agenda  Distributed Architectures – Remote and Local Interfaces – Where You Have to Distribute – Remote Façade  Scalablity  DEMO
  26. 26. Distributed Architecture  Distribute processing by placing objects different nodes
  27. 27. Distributed Architecture  Distribute processing by placing objects on different nodes  Benefits – Load is distributed between different nodes giving overall better performance – It is easy to add new nodes – Middleware products make calls between nodes transparent But is this true?
  28. 28. Distributed Architecture  Distribute processing by placing objects different nodes “This design sucks like an inverted hurricane” – Fowler Fowler’s First Law of Distributed Object Design: Don't Distribute your objects!
  29. 29. Remote and Local Interfaces  Local calls – Calls between components on the same node are local  Remote calls – Calls between components on different machines are remote  Objects Oriented programming – Promotes fine-grained objects
  30. 30. Remote and Local Interfaces  Local call within a process is very, very fast  Remote call between two processes is order-ofmagnitude s l o w e r – Marshalling and un-marshalling of objects – Data transfer over the network  With fine-grained object oriented design, remote components can kill performance  Example – Address object has get and set method for each member, city, street, and so on – Will result in many remote calls
  31. 31. Remote and Local Interfaces  With distributed architectures, interfaces must be course-grained – Minimizing remote function calls  Example – Instead of having getters and setters for each field, bulk assessors are used
  32. 32. Example  Sun Application Model – “The Canonical Architecture”  Entity Beans – Each bean maps to row in the database – find methods returns Collection of Remote interfaces
  33. 33. Example  Result – Architecture that does not perform very well  Suggested solution was – Use session beans to call entity beans
  34. 34. Distributed Architecture  Better distribution model – Load Balancing or Clustering the application involves putting several copies of the same application on different nodes
  35. 35. Where You Have to Distribute  As architect, try to eliminate as many remote call as possible – If this cannot be archived choose carefully where the distribution boundaries lay  Distribution Boundaries – – – – – Client/Server Server/Database Web Server/Application Server Separation due to vendor differences There might be some genuine reason
  36. 36. Optimizing Remote Calls  We know remote calls are expensive  How can we minimize the cost of remote calls?  The overhead is – Marshaling or serializing data – Network transfer  Put as much data into the call – Course grained call  Remote Façade
  37. 37. Remote Façade Provides a coarse-grained facade on fine-grained objects to improve efficiency over a network  The façade is a thin wrapper that provides coarse-grained interface to a system – In an object-oriented model, you do best with small objects that have small methods – Can cause great deal of interaction between objects and method invocations
  38. 38. Remote Façade  How It Works – Allows efficient remote access with coarse-grained interface – Façade will use the fine-grained object to build and return object like Data Transfer Object – Should not contain any domain logic
  39. 39. Remote Façade  When to Use It – Whenever you need remote access to fine grained object model – Most common use is between UI and domain model
  40. 40. Remote Façade  Remote method invocation are expensive – Performance killer RMI Client JVM Entity Entity Session Session Entity
  41. 41. Remote Façade  Coarse grained interface JVM Client RMI Local calls Entity Remote Façade Entity Session Session Entity
  42. 42. Remote Façade  Benefits – Net traffic is reduced – Transactions are closer to the database  Drawbacks – Limitations on object oriented programming – Solution is based on limitations of the network
  43. 43. Interfaces for Distribution  XML over HTTP is a common interface – XML is structured and allows for lot of data – XML is common format, well known – HTTP is common and esay to use  XML has overhead – Parsing and manipulation of strings is expensive – Overhead if not needed  Approches like REST are more efficient – Use HTTP right
  44. 44. Scalability
  45. 45. Scaling the application  Today’s web sites must handle multiple simulations users  Examples: – All web based apps must handle several users – mbl.is handles ~180.000 users/day – Betware must handle up to 100.000 simultaneous users
  46. 46. The World we Live in  Average number of tweets per day 58 million  Total number of minutes spent on Facebook each month 700 billion  SnapChat has five million daily active users who send 200 million photos per day.  Instagram has over 150 million users on the platform and1 billion likes happening each day
  47. 47. Scalability  Scalability is the measure of how adding resource (usually hardware) affects the performance – Vertical scalability (up) – increase server power – Horizontal scalability (out) – increase the servers  Session migration – Move the session for one server to another  Server affinity – Keep the session on one server and make the client always use the same server
  48. 48. Scalability Example
  49. 49. Load Distribution  Use number of machines to handle requests  Load Balancer directs all request to particular server – All requests in one session go to the same server – Server affinity  Benefits – Load can be increased – Easy to add new pairs – Uptime is increased  Drawbacks – Database is a bootleneck
  50. 50. Clustering  Distributing components – Each node has one component – Increased performance is not guaranteed  Using cluster – Have all components in each node and use local calls
  51. 51. Clustering  With clustering, servers are connected together as they were a single computer – Request can be handled by any server – Sessions are stored on multiple servers – Servers can be added and removed any time  Problem is with state – State in application servers reduces scalability – Clients become dependant on particular nodes
  52. 52. Clustering State  Application functionality – Handle it yourself, but this is complicated, not worth the effort  Shared resources – Well-known pattern (Database Session State) – Problem with bottlenecks limits scalablity  Clustering Middleware – Several solutions, for example JBoss, Terracotta  Clustering JVM or network – Low levels, transparent to applications
  53. 53. Scalability Example
  54. 54. Measuring Scalability  The only meaningful way to know about system’s performance is to measure it  Performance Tools can help this process – Give indication of scalability – Identify bottlenecks
  55. 55. Example tool: LoadRunner
  56. 56. Example tool: JMeter
  57. 57. QUIZ Which is true when you are clustering your application? A) Make sure all requests goes to the same machine B) Deploy each component on separate machine to distribute load C) You try to minimize network traffic to avoid latency problems D) Deploy the whole solution on many machines
  58. 58. Real World Examples: Betware Iceland Data Center
  59. 59. ISP1 ISP2 Hardware firewall Load balancer Backup Software System DB 16 port 2Gbps SAN switch QLogic CMS DB 12 x 300GB SAS 15K 24 x 300GB SAS 15K Pair of each server on separate blade IBM Blade Chassis
  60. 60. Summary  Session State – Business transactions  Session State Patterns – Client Session State – Server Session State – Database Session State  Distribution Strategies – How to distribute