Pekny den
Diky za odpoved. Stavajici reseni je ciste takove ze si klient posila
se servrem xml stringy - ktere ale semanticky odpovidaji databazovym
dotazum/prikazum.
Napsat vlasni JDBC driver (ktery preklada sql do proprietalniho jazyka
xml) se mi zda jako vtipne reseni - zkusim to za dlouhych zimnich
veceru, az nebudu mit co delat.
Stavajici framework je velicie neprehledny (vznikal jako snehova
koule) a mam moznost jeho vnitnosti prepsat (vyextrahovat api a
reimplementovat streva). Jde mi o to, ze se mi nechce psat dalsi
framework, kterych uz je na svete tuna. Proto jsem se ptal na nejake
hotove reseni.
btw: jak by jste resili situaci, kdy mate standardni j2ee server a
tlusteho klienta ve swingu? Tam hibernate na strane klienta pouzit
nelze. Pro notifikace se serveru by slo pouzit JMS - nebo by bylo lepsi
reseni s JBoss TreeCache?
Diky
Petr Charvat
Roman Kratochvil wrote:
Dobry den,
s popisovanou architekturou tlusteho klienta i s jejimi variantami mam
sve urcite zkusenosti, a proto mozna bude znit tato rada zvlastne,
ale: pokud je jedinym problemem, ktery resite, mnozstvi dat na
klientovi, a zbytek funguje ok, tak udelejte co nejmene, usetrite si
tak *mnoho* dalsich problemu. V prvni rade bych zkusil tu cache na
klientovi implementovat ve stylu LRU, aby se pri vhodne prilezitosti
(konec transakce, nebo nejak asynchronne) z ni dlouho nepouzivana data
odstranovala.
Reseni ala hibernate (nebo ala JDBC nebo ala cokoliv takto
"dvouvrstveho") ma svuj primarni problem ve vykonu: pokazde se budete
serveru dotazovat na data, ktera potrebujete. Bylo by pro vas skvele,
kdybyste zjistili, ze je nepotrebujete cachovat vubec, ze i tak je
vykon dostatecny; ovsem to zrejme neodpovida vasi situaci, kdyz uz
cache na klientovi mate. Pokud si ta data budete cachovat, tak opet
resite problem z prvniho odtavce, nezavisle na pouzitem frameworku. Je
otazka, zda se vam kompletni prepis za techto okolnosti vyplati.
Samozrejme, muzou k nemu byt i jine duvody (kod je neudrzovatelny
apod.), to uz ja nevim.
Roman
----- Original Message ----- From: "Charvat Petr" <[EMAIL PROTECTED]>
To: "Java" <[email protected]>
Sent: Wednesday, August 02, 2006 1:06 PM
Subject: vhodny framework pro tlusteho klienta
Zdravim,
Delame tlusteho klienta ve swingu, ktery komunikuje se
specializovanym serverem (c++). Ten se stara a konfiguraci a
monitoring pomerne sloziteho hardwaru (predstavte si treba velkou
telefoni ustrednu kterou je mozno konfigurovat az to hezke neni).
Klient zobrazuje a umoznuje zadavat a menit data (konfiguruje
telefoni karty)- v podstate standardni insert/update/delete operace.
Server si data uklada do sve databaze - oracle. Veskera komunikace se
serverem je pres corbu. Stavajici implementace pouziva pro datove
toky (ins/up/del) xml notifikace ve ktere se posle celky objekt (v
podstate jedna radka databazove tabulky). Dalsi zajimava vlastnost je
ta, ze kdyz jeden client zmeni nejaky objekt (provede transakci),
server notifikuje ostatni klienty a ti provedou refresh.
Toto reseni je nejake (historicky) a celkem funguje dobre. Bohuzel
jsme se dostali do stavu, kdy na strane klienta se drzi velke
mnozstvi informaci o objektech (cache) a toto je velice memory
consuming. Jsme tedy ve stavu, kdy musime prepsat persistentni vrstvu
na strane klienta (nejen kvuli pameti ale i kvuli maintenance, speed
...). V tuto chvili mi jde o to rozhodnout, jestli neexistuje nejake
uz hotove reseni (knihovna, framework apod) ktere by tento ukol plnilo.
Libilo by se mi pristup jaky ma hibernate ale s tim, ze nema za
sebou databazi, ale svuj persistentni stroj (xml->server). Neznate
neco nakoveho?
Diku
Petr Charvat
PS: Predesilam ze s architekturou celeho systemu se neda momentalne
nic delat. Jde mi ciste o stranu klienta.
