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:
http://www.olafurandri.com/?page_id=2762
4. Agenda
Session State
– Business transactions
Session State Patterns
– Client Session State
– Server Session State
– Database Session State
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. 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. Stateless Servers
Stateless servers scale much better
Use fewer resources
Example:
– View book information
– Each request is separate
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. 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
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. Ways to Store Session State
Three basic choices
– Client Session State (456)
– Server Session State (458)
– Database Session State (462)
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. 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. 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. 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. 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. 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. 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. 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. 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. 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
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. 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. 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. 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. 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. 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. Example
Result
– Architecture that does not perform very well
Suggested solution was
– Use session beans to call entity beans
34. Distributed Architecture
Better distribution model
– Load Balancing or Clustering the application involves
putting several copies of the same application on
different nodes
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. 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. 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. 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. 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
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. 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
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. 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. 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
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. 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. 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. 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
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
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
63. Summary
Session State
– Business transactions
Session State Patterns
– Client Session State
– Server Session State
– Database Session State
Distribution Strategies
– How to distribute