state processes and cloud - edition 2014

State, Processes and Cloud

Edizione 2014Marco Parenzan

“Classic” OOP

Traditional OOP techniques applies to a traditional execution environment“infinite resources”

Focus on “good” algorithmFocus on functional objectives

Never on non-functional objectives

An “universal” objectOne object good for all

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 contemporaryso buy 10

Web scenarios have introduced “connection pooling” Fast Open/Close connection simulating an “always connected” (now theoretical) scenarios

Web is definitely “not traditional”

Multi user environmentMemory Constraints (tot kb per user)

Long latency (milliseconds)Long request distance (seconds)Disconnected (HTTP)

No state

Statefulness and Statelessness

Statefulness is having stateStatelessness is NOT having state….without user interaction…

HTTP statelessness

Distinct HTTP calls have no relationship each otherNo memory shared between distinct callsResponse 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

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

Session abuse

Store data in session, accesses minutes “after”Memory consumption for unuseful data

AffinityIn THAT memory, in that computer, in that host!!!!No other host have the same data

HTTP sessions and requests

Session must be used more less as we canRequest must be satisfied just in request time

with request dataAt least recover data just in the request

Stale data

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

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 variablesLow risk of stale dataRisk of affinity

Session and cache

Saving data (in session) and caching are two (very) different things

CacheCopy of dataRisk of stale dataBut Fast

Result of a query, for example

One model does not fits for all

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

REQUESTDifferent 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)

How many ways to model an object

1.1

2.None

3.100000

4.infinite?

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

“One way, or another…” (Blondie, 1979)

How many ways to model objects?How many ways to model THE SAME entity into

DIFFERENT objects?

State, Processes and Cloud

Edizione 2014Marco Parenzan