high performance middle vrstva

[Stanislav Poljovka]

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