Charvat Petr wrote:
Dekuji vsem na odpoved. Musim projit vsechny doporuceni co jste mi
dali a uvidim (dam vedet).
Uvazoval jsem i nad resenim, ze bych stavajici server psany v c++
premostil standardnim j2ee serverem, ke kteremu by se 'tlusti' klienti
pripojovali (proste bych mezi stavajici server a klienta strcil dalsi
server - ktery je ale prece jen standardizovanejsi. Predpokladam, ze
pro reseni j2ee server + tlusy klient nejaky hotovy framework existuje
(na tenkeho kliena jich je kazdopadne tuna).Tim bych presunul podivnou
komunikaci pres xml na server a klienti by se pres standardni session
beans komunikovali se javovym serverem. Pokud by tedy novy server umel
odpovidat a notifikovat rychle - na strane klienta bych ani nemusel
stavet cache.
Jak se divate na takove reseni?
Mne osobne by takovy framework zajimal ;-)
Hlavne jakou konsitenci a odezvu takovy framework bude mit (dle
http://www.cis.upenn.edu/~lee/06cis505/Lec/lec-ch6b-replication-v1-six.pdf).
Protoze v distribuovanych systemech plati, ze cas cteni + cas zapisu >
latence site (optimalizace na cteni zpomaluje zapis a naopak).
Myslim, ze 3 vrstva architektura je tu prave proto, aby na klientovi
takova cache nemusela byt.
Lukas
PS: uz par mesicu pisu tlusteho klienta, ktery pouziva Hibernate a
problem neaktualnich dat obchazime optimisticky - vlastneni dat a
verzovani dat.
