Home > Polish > Page pooling w T5

Page pooling w T5

W poprzednim wpisie wspomniałem, że do wersji 5.2, wszystkie strony w Tapestry były przetrzymywane w puli. Niestety poprzedni wpis się rozrósł i postanowiłem stworzyć krótszy wpis poświęcony temu zagadnieniu.

W poprzednim wpisie pokazywałem jak można zarządzać stanem strony. Jedną z zalet programowania w T5 jest wrażenie, że strony dają poczucie bycia świadomymi swojego stanu. Wystarczy mała adnotacja, bądź metoda i programujemy  nie przejmując się skąd pobrać wartości dla kolejnego żądania od klienta. Osobiście miałem ten problem, gdy korzystałem z innych szkieletów, wiem że inni też go miewali. Każda osoba pisząca ukryte pola, bądź kombinująca nad sesją ręka w górę ^^

Niestety zachowywanie stanu ma swoje wady. Dane trzeba gdzieś trzymać i jakoś je ładować. Dla developera i klienta, strona może i wygląda jakby cały czas miała zapisane wartości, ale tak nie jest. Tapestry podczas każdego redirecta, zapisuje dane do wyznaczonego przez nas miejsca (przeważnie do sesji), po czym wysyła stronę do puli a następnie pobiera stronę o którą prosi użytkownik (może być ta sama) i ustawia property z nią związane (adnotowane np persistem, bądź będące w cyklu aktywacji/deaktywacji). Dłuższe i sensowniejsze wyjaśnienie cyklu życia i stanowość opisane są tu, tu i tu.

Podejście to ma jednak wady. Trzymanie wielu instancji strony jest kosztowne. Każda z nich zajmuje pewną ilość pamięci co przy wielu stronach i wielu klientach doprowadzi do zużycia dużej ilości pamięci. Alternatywnie można by tworzyć dla każdego klienta instancję strony i niszczyć tuż po użyciu, niestety strony w Tapestry wymagają dużo zasobów do ich stworzenia, a to nie pomaga gdy użytkownik czeka na swoją stronę. Pula jest więc dobrym pomysłem, jednak stwarza problem dla dużych serwisów, gdzie zużywana pamięć bywa już problemem. By wyjść naprzeciw oczekiwaniom developerów, od wersji 5.2 pulę zastąpiono poprzez singletony stron. Dzięki sprytnemu zabiegowi, dla każdej strony tworzona jest tylko jedna instancja, co jak łatwo się domyślić przekłada się pozytywnie na ilość zużywanej pamięci. Obecnie mechanizm wygląda tak, że Tapestry pakuje w mapę wszystkie wartości, związane z stroną, i w przypadku żądania od klienta wykorzystuje je do zasilenia obiektu strony. Więcej o nowym mechanizmie (i bardziej szczegółowo) można przeczytać na blogu Howarda Lewisa Shipa. Wpis ten tłumaczy koncepcję i implementację nowego mechanizmu. Polecam zainteresowanym.

Ostatnia sprawa. Jednym z czynników, dla których poruszam ten temat, jest to, że jest to spora zmiana. Kto czytał o Tapestry więcej, wie że większe zmiany powodowały duże problemy z wsteczną kompatybilnością. Tu jednak nie tylko został zachowany stary mechanizm (można aktywować pulę i zrezygnować z singletona), ale ponadto pula została rozszerzona. Od ver 5.2 da się zarządzać nią zdalnie i dostosowywać jej wielkość do aktualnych potrzeb (wcześniej było to możliwe tylko podczas kompilacji, ewentualnie przez properties i reload aplikacji). Mechanizm ten opisał na swoim blogu Igor Drobiazko. Podobne zachowanie kompatybilności wstecz, przy rozwijaniu frameworku, można zaobserwować w sprawie bibliotek javascriptowych. Na liście non stop powraca temat zastąpienia obecnych bibliotek poprzez jquery i non stop jest odrzucany wraz z przekierowaniem do projektów, które pozwalają na ową integrację. Nie bójcie się więc T5, ono nie planuje się zmieniać, przynajmniej nie rewolucyjnie :)

Advertisements
Categories: Polish Tags:
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: