Play2 Framework - brak sesji. Dlaczego?

Hej.

Play2 ma podejście pełnej bezstanowości po stronie serwera, co wiąże się z brakiem sesji. Braki są trochę na siłę załatane podpisanym ciachem, czyli stanowość jednak jest, ale nie po stronie serwera.

I moje pytanie brzmi: Dlaczego zastosowali takie podejście? W czym jest ono lepsze od stosowania sesji?
Ja rozumiem że w http jest w założeniu bezstanowy, ale to było projektowane bardzo dawno temu. Teraz wszędzie jest logowanie czyli stanowość i nikt nie ma z tym problemu. Więc jaki jest plus takiego założenia?

Teraz wszędzie jest logowanie czyli stanowość i nikt nie ma z tym problemu.

W Play tez przeciez jest i tez nikt nie ma z tym problemu. :\

Więc jaki jest plus takiego założenia?

Skalowalnosc.

Ok. Ale w play jest stan trzymany w ciachu, czyli i tak jest ta informacja trzymana, przekazywana i znana. W czym to rozwiązanie poprawia skalowalność w porównaniu do podejścia z sesją? Przecież rozwiazania JEE/Spring też są uważane za bardzo skalowalne a posiadają mechanizm sesji.

krzysiek050 napisał(a):

Teraz wszędzie jest logowanie czyli stanowość

Nie, logowanie i stanowość to dwie zupełnie rzeczy i niekoniecznie powiązane ze sobą. Cały REST opiera się na bezstanowości, po prostu każde żądanie zawiera dane niezbędne do uwierzytelnienia użytkownika.

No ok. Rozumiem to. Ale to jest tylko filozofia. Efekt jest przecież ten sam, czyli znam tożsamość użytkownika. Za to takie rozwiązanie posiada minusy:

• Nie mogę nic ukryć przed użytkownikiem.
• Sprawdzanie podpisu per request - zapewne wolniejsze niż powiązanie jsessionid z danymi.

Nie bardzo rozumiem, czego nie możesz ukryć.

Nie jest ten sam. Sprawdzanie podpisu per request choć wolniejsze (ciekawe o ile) pozwala na znacznie lepszy loadbalacing całego rozwiazania. W klasycznym podejściu gdy masz cluster loadbalacer musi:
a) kierować danego użytkownika na konkretny serwer na którym się zalogował i który ma jego sesję w pamięci. Wada - jak serwer padnie to sesja razem z nim.
b) każdorazowo zapisywać i odtwarzać stan sesji z np. bazy danych jeżeli kieruje do "pierwszego wolnego". Wada - serializacja sesji jest strasznie powolna...

Brak sesji w taki sposób jak realizuje to Play2 łączy zalety klasycznych podejść tzn. masz failover, skalowalność horyzontalną i ogólnie zapewnienie "ciągłości działania" jednocześnie zapewniajac bardzo sprawną obsługę autoryzacji i autentykacji.

Bardzo rzeczowa odpowiedz. Dzieki :).