More on Session State

Transcription

1 More on Session State Mostly we have assumed sticky sessions session bound to app server instance Even that is harder than you think: Servlet spec explicitly allows concurrent requests in the same session A single HttpSession object is shared by multiple threads So all code must be thread-safe! Oops!

2 For Instance Keep shopping cart in session data total cost (an Integer) order lines (in a collection data structure) Update total cost when adding an item? not so easy

3 For Instance, continued Concurrently add two items to cart: tmp := cost tmp := tmp cost := tmp tmp := cost tmp := tmp cost := tmp Classic concurrent update error!

4 For Instance, continued It is not very common for a user to click add item in two windows simultaneously Good thing -- this kind of bug appears in sample code all over the Web!

5 Some Philosophy Replicating data with tolerable efficiency requires some notion of transaction (granularity of changes being replicated) Servlet API doesn t have a good channel for this information

6 Application Server Session Replication Naive view (really easy for Load Balancer) Load Balancer Replicate data among servers Choose server at random Application Servers

7 Problems - Scaling Memory every server has a copy of all sessions Processing and Network every server must handle updates for all sessions

8 Problems - Consistency How ensure an application that is correct on a single server remains correct when replicated? every data change is replicated instantaneously? distributed lock manager for inter-server synchronization? prohibitively expensive -- no implementation does it (to my knowledge)

9 Details Even with ABCAST get inconsistencies A1 changes S to S A2 changes S to S A1 broadcasts S A2 broadcasts S A1 receives change S to S A2 receives change S to S -- INCONSISTENT -- Fix: ABCAST all changes, apply local changes when received (not when sent) API doesn t provide enough information

10 Typical Implementation Multicast session changes when a Servlet returns, or periodically Neither guarantees consistency in the (admittedly infrequent) case of concurrent activities in the same session

11 Application Server Session Replication Primary-Backup (really easy for Load Balancer) Load Balancer Replicate data to backups Choose primary server only Application Servers

12 Failover Choose a new primary Load Balancer Replicate data to backup Choose primary server only Application Servers

13 Recovery Bulk transfer session data to recovering server Load Balancer Choose primary server only Replicate data to backup Bulk transfer data to recovering server Application Servers

14 Properties Replication is much easier because there is only one source of updates at any time copy on servlet exit, or copy periodically but copy only when no servlet is running in the session (consistency) so if servlets run concurrently, can t copy on every servlet exit performance/timeliness tradeoff okay if some loss of session data can be tolerated

15 Disadvantages The obvious big one... Load Balancer These servers aren t being used! Application Servers

16 Partitioning more work for load balancer Partition sessions into n groups (e.g. by hashing) Each server is primary for one group and backup for another Load Balancer Application Servers

17 k-partitioning Partition sessions into kn groups of size g yet more work for load balancer Each server is primary for k groups and backup for (g-1)k groups Each server does W(g/n) updates/sec (indep of k) On failover, local update rates of k servers increase by factor of (k+1)/k (indep of g) Fairness: when one server fails, its load is taken up by k servers, not just one

18 Back-of-Envelope Calculation

19 k-partitioning, continued Note: no persistent storage if g or more servers fail, some session data may be lost choose larger g to ensure reliability A perfectly viable scheme -- variants are widely available (including JBoss)