Why state is important? Why objects cannot be written with a "common" OOP approach where developing for #cloud?

1. State, Processes and Cloud
Edizione 2014
Marco Parenzan

2. “Classic” OOP
Traditional OOP techniques applies to a traditional
execution environment
“infinite resources”
Focus on “good” algorithm
Focus on functional objectives
Never on non-functional objectives
An “universal” object
One object good for all

3. RDBMS already “not traditional”
 Relational DataBase Management Systems already not traditional
 It costs…licencing
 Fixed price + tot x (group of) users
 It costs…memory
 Buffer to prepare resultsets, tipically
 So don’t abuse
 Contemporary users is a way to measure, not just “all users”
 15 users, 10 contemporaryso buy 10
 Web scenarios have introduced “connection pooling”
 Fast Open/Close connection simulating an “always connected” (now theoretical) scenarios

4. Web is definitely “not traditional”
Multi user environment
Memory Constraints (tot kb per user)
Long latency (milliseconds)
Long request distance (seconds)
Disconnected (HTTP)
No state

5. Statefulness and Statelessness
Statefulness is having state
Statelessness is NOT having state
….without user interaction…

6. HTTP statelessness
 Distinct HTTP calls have no relationship each other
No memory shared between distinct calls
Response is done with call informations and access to other data
sources (with key in the call)
 In general, two different calls can be handled by two different
processes
In general processes don’t share memory (virtual space protection)
 In (very) general form, two requests can be handled by two
different hosts

7. HTTP “statefulness”
 HTTP simulate statefulness with cookies
 A cookie is a key sent for the first time by HTTP server and always
submitted by browser requesting something to the same server
 A session is a “state” keyed by cookie and stored in memory
 Cookies have timeout
 Days (for user/related content)
 Minutes (for session related content)
 After timeout, state is lost
 After a single call, timeout counting is restarted

8. Session abuse
Store data in session, accesses minutes “after”
Memory consumption for unuseful data
Affinity
In THAT memory, in that computer, in that host!!!!
No other host have the same data

9. HTTP sessions and requests
Session must be used more less as we can
Request must be satisfied just in request time with
request data
At least recover data just in the request

10. Stale data
Stale data are copies of data…
…that can become old…fast!
Unaligned from “official” data source
Do you have session or cache????
Be conscious having date that can be stale

11. Session and cache
Saving data (in session) and caching are two (very)
different things
Session
“State of the art” data
If you don’t use it as a cache
Like variables
Low risk of stale data
Risk of affinity

12. Session and cache
Saving data (in session) and caching are two (very)
different things
Cache
Copy of data
Risk of stale data
But Fast
Result of a query, for example

13. One model does not fits for all

14. So back to OOP: what is OOP?
OOP is no more a way to model state of a program…
…OOP is a way to implement a response to a
REQUEST
Different kind of request needs different kind of
objects and ways to write objects (and code)
And different performance (without saying that every call
must be fast)

15. How many ways to model an object
1.1
2.None
3.100000
4.infinite?

16. A single model cannot solve every
problem
A single model cannot be appropriate for
reporting, searching, and transactional
behaviors…
A single model can cost more that the sum of the
many useful representations

17. “One way, or another…” (Blondie, 1979)
How many ways to model objects?
How many ways to model THE SAME entity into
DIFFERENT objects?

18. State, Processes and Cloud
Edizione 2014
Marco Parenzan