Play2 Framework - brak sesji. Dlaczego?

Odpowiedz Nowy wątek
2014-12-16 15:22
0

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?

Pozostało 580 znaków

2014-12-16 15:29
1

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.

Pozostało 580 znaków

2014-12-16 15:57
0

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.

Pozostało 580 znaków

2014-12-16 21:25
1
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.

Pozostało 580 znaków

2014-12-17 08:33
0

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.

Pozostało 580 znaków

2014-12-17 08:58
1

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

Pokaż pozostałe 7 komentarzy
Ale wtedy powstanie coś ala serializacja sesji którą opisał Koziołek niżej. Dodatkowo sam będę musiał tym zarządzać. - krzysiek050 2014-12-17 11:28
Niekoniecznie. Serializacja o ktorej mówię dotyczy CAŁEJ sesji wraz z przyległościami. Tu serializujesz tylko część biznesową. Zresztą jakoś koszyk przechowywać musisz w takim modelu (baza danych) zatem i tak mechanizm musisz w jakiś sposób napisać. - Koziołek 2014-12-17 11:31
A jakie przyległości zawiera np. Spring? Tzn nawet dla tego przykladu, co oprócz koszyka i username. A koszyka nie musiałbym tworzyć gdybym miał go w sesji i po akceptacji wrzucał prosto jako zamówienie. - krzysiek050 2014-12-17 11:38
na przykład atrybuty sesji (z kontenera), listenery, kontekst itp. Pamiętaj, że ty widzisz w swoim kodzie tylko "użyteczną" część frameworku, bez bebechów. - Koziołek 2014-12-17 11:56
Ok. Dzięki wam za dyskusję. Trochę mi w głowie pojasniało :). - krzysiek050 2014-12-17 12:10

Pozostało 580 znaków

2014-12-17 08:59

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.

Pozostało 580 znaków

2014-12-17 09:08
0

Bardzo rzeczowa odpowiedz. Dzieki :).

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0