Ohľadom rýchlosti - nejde mi o nejakú tú milisekundu, skôr je podstatné, aby jeden server utiahol čo aby najviac klientov. Medzivrstvu vytvoriť musím, ako som už písal, mám M klientov, ktorí lezú do N databáz. Občas však musím nejakú databázu odobrať alebo pridať. Bolo by veľmi zložité aktualizovať konfiguráciu pre všetkých M klientov. Použitie medzivrstvy by bolo podľa mňa oveľa jednoduchšie.
Web aplikácia pristupuje k DAO cez interface, inštancie dao získava z DaoFactory - takže prechod na medzivrstvu bude len prepísanie daofactory. Potreboval by som skôr vedieť, či použiť nejaký aplikačný server so stateless ejb, alebo samostatnú JVM aplikáciu, na ktorú by sa klienti pripájali cez RMI(prípadne Hessian, ďakujem za upozornenie na túto technológiu). V súčasnosti nepoužívam žiaden pool na dao - pri každej akcii sa dao(trieda neobsahuje žiadne atribúty) vytvorí a po skončení ho zase musí garbage collector zlikvidovať. To je asi chyba. Dá sa implementovať nejako jednoducho pool na stateless klassy aj bez aplikačného servra? 2009/9/14 Stanislav Poljovka <[email protected]> > > Ja by som to riesil nasledovne: > 1) premenovanie implementacie povodnych DAO tried pre pristup do lokalnej > databazy > 2) extrakcia metod (pull-up) do DAO interface-u pri zachovani povodneho > pomenovania DAO tried > 3) implementacia DAO tried na pristup cez RMI/REST/Hessian ... na ine > servre a samozrejme aj serverovu cast pre dany typ komunikacie. Mozete sa > inspirovat clankom > http://daniel.gredler.net/2008/01/07/java-remoting-protocol-benchmarks/ > > Neviem, ako ziskavate instancie DAO objektov, ale ak: > > A) DAO mate spravovane cez spring, potom vsetky potrebne kombinacie > pouzitia treba riesit viacerymi konfiguraciami spring bean-ov. Potom nie > potrebne menit zvysok aplikacie (lebo DAO je interface s povodnym menom a > ten teraz odkazovany v business / service vrstve). Horsie to bude z > build-ovanim aplikacie alebo z deploymentom (buildovat vsetko a konfiguracne > urcit, ktory sping beans sa ma pouzit). > > B) DAO mate spravovane manualne, tak to bude potrebne upravit v > business/service vrstve asi nasledovne: > 4) Vytvorit DAOHelper, ktory by podla potreby (on demand) / konfiguracie / > service API / .. zpristupnil (cez spring / factory / ..) prislusne DAO > objekty > 5) zmenit ziskavanie instancie DAO v business / servisnej vrstve ... nieco > ako MyDAO myDao = DAOHelper.getDAO(MyDAO.class) alebo = > DAOHelper.getDAO(MyDAO.class, "serverA") > Pozn.: Tu by som zvazoval radsej to prerobit na sposob A), ale to nemusi > byt priechodne (ak napr. potrebujete robit naraz z objektami rovnakej triedy > z roznych zdrojov / DB / .. on demand z dopredu stanovenymi serverami). > > Ohladne tej vykonosti, by som zvazoval zavedenie > distribuovanej/cluster-ovej cache (napr. Terracotta + ehcache). Aj ked, ako > si tak uvedomujem, tak to nemusi mat pozitivny vykonnostny efekt pre > persistente objekty z druhej DB, lebo je takmer jedno ci sa kumunikuje cez > RMI / REST / ... alebo cez komunikacne kanaly terracotta-y (hlavne pri > vysokom zatazeni). > > Stano > > salmonel salmonel wrote: > > Dobrý deň, > > > > mám web aplikáciu v jave, je napísaná v Spring web flow, používa > Hibernate pre perzistenciu objektov. K hibernate pristupujem vždy cez DAO. > > > > Momentálne aplikácia beží v tomcate. Potrebujem pridať medzi databázu a > tomcat vrstvu, v ktorej by boli všetky dao objekty. Na servroch nám totiž > beží niekoľko inštancií našej aplikácie(máme niekoľko klientov), tieto > inštacie majú každá vlastnú databázu. Niekedy však potrebuje jedna inštacie > liezť aj do databáze druhej inštancie. Preto chcem centralizovať prístup k > databázam. > > > > Podstatné je, že potrebujem pridať vrstvu, v ktorej by boli len DAO > objekty. Podľa toho, čo som pochopil mám na výber medzi EJB statless beanami > bežiacimi v JBOSSe(prípadne inom aplikačnom servri), alebo si spraviť > vlastnú aplikáciu, ktorá by obsahovala dao objekty a fungovala ako RMI > server. Tomcat by bol RMI klient a vždy kontaktoval server. O pooling > databázových pripojení by sa postaral hiberante. > > > > Aplikácia už je naprogramovaná, iné výhody EJB asi nevyužijem. Ide mi > najmä o vysoký výkon a budúcu škálovatelnosť(s ktorou by nemal byť problém, > ide o stateless objekty, takže môžem nasekať koľko chcem RMI servrov, ktoré > nemusia medzi sebou komunikovať). > > > > Ďakujem > > >
