2009/9/15 Roman Pichlík <[email protected]>: > Ja to nechapu :-). Tim, ze pridate RMI a centralizujete to jednoho mista tak > si prece vubec nepomuzete. RMI vam prinese overhead v podobe > serializace/deserializace. Tim, ze to centralizujete, budete muset resit > rozlozeni zateze na ten centralni uzel. Jinymi slovy jedine co vam to > prinese bude slozitejsi deployment. Navic to zpusobi, ze klienti se budou > vzajemne ovlivnovat.
No ja bych sel jeste dal: jaky je duvod umoznit pristup uzivateli A do databaze uzivatele B? Tady bych videl onen zasadni problem. > Pokud jsou vase DAO objekty stateless, tedy nemaji zadny stav, tak nevim co > resite. Poolovani jejich instanci je zbytecnost vzhledem k efektivite > dnesnich garbage collectoru. Osobne bych mel pro kazdou z tech aplikaci > vlastni instance te DAO vrstvy s ruznou konfoguraci kde bude recene na jake > DB se maji pripojit. Ta predpokladana mezivrstva by asi mela fungovat jako wrapper kolem sdilenych DB, je to tak? Je otazka, jestli to ma smysl nejak dramaticky resit a nenechat to opravdu primo na databazovem stroji (nepredpokladam, ze to bezi nad embedded Derby nebo hsqldb). Je pak samozrejme potreba DAO vrstve vysvetlit, ze si nema cachovat data (prestoze jsou stateless), protoze by je mohl chtit "zmenit/smazat/..." nekdo z druhe aplikace. Teprve pokud se ukaze, ze dat je tolik a maji takovou strukturu, ze je nutne je drzet v pameti v podobe DAO, pak bych onu vrstvu resil. Myslim si ale, ze toto je pripad tak jedne z tisice aplikaci... tem zbylym 999 aplikacim povetsinou staci se poradne podivat na SQL dotazy a indexy... Mozna bych na konec doporucil jednu vec - pokud jsou ta sdilena data sdilitelna pres vsechny aplikace, vytvoril bych si jednoduchou knihovnu, ktera mi k nim bude pristupovat. Pak tuto knihovnu lze AZ v pripade potreby zaRMIckovat, jinak to honit lokalne per instance aplikace. > Ondra Medek napsal(a): >> >> Krome hessian je take pomerne rychly JBoss remoting >> >> >> http://www.theserverlabs.com/blog/2009/02/19/jboss-remoting-jboss-serialization-kills-javarmi-and-spring-remoting/ >> >> ma par dalsich ficur navic v porovnani s RMI. >> >> Co se tyka poolu na DAO, tak existuje na to nejaky Apache projekt >> http://commons.apache.org/pool/ (blize to neznam). Ovsem pokud jsou >> tvoje DAO jednoduche na inicializaci a ruseni, tak je nema smysl >> poolovat. Alokace pameti v Jave je rychlejsi nez v C. Poolovani ma >> smysl, az kdyz se provadi nejake slozite inicializace. >> >> Otazka jestli nejaky aplikacni server se session beans nebo ne je tedy >> spise otazka, co muze app. server nabidnout navic k obycejnemu >> RMI-like reseni. Podle meho nazoru to muze byt treba (JBoss) to >> poolovani, transakce, moznost mit vice verzi aplikace pres classloader >> isolation, pohodlne vyvareni administratorskeho rozhrani k aplikaci >> pres MBeany nebo servlety, a muzes si psat JavaEE do CV :-))). Dale >> treba muzes v budoucnu potrebovat distribuovanou cache, nebo i treba >> stateful beanu v distribuovanem prostredi. Pokud nic z toho >> nepotrebujes (a potrebovat nebudes), tak se klidne app. serveru vyhni. >> >> My mame Java Swing aplikaci a mezivrstvu pres stateful beans na >> JBossu. V podstate vyuzivame hlavne moznost snadneho deploy nove verze >> (se zachovanim te stare, klienti se neupdatuji najednou) a jednu >> MBeanu pro zakladni informaci o behu aplikace (viditelne pres web >> rozhranni nazyvane JMS console). >> >> >> 2009/9/14 salmonel salmonel <[email protected]>: >>> >>> 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 >>>> >>> >> >> >> > > > -- > S pozdravem Roman "Dagi" Pichlik > > /* http://www.sweb.cz/pichlik/ Blog pro kodery */ >
