Ales Dostal napsal(a):
Jeste jednou diky. Jinak jak se mam divat na to,ze samotny glassfish
si ubira porad dalsi a dalsi pamet, kterou neni mozne pomoci GC
odstranit.
Mam to chapat tak, ze po dovrseni max velikost dovolene pameti, kterou
ma k dispozici pretece nebo zacne uvolnovat z pameti, co jiz nepotrebuje?
Pokud bych to mel popsat na Hibernatu (pokud vim, tak by to platilo i
pro EJB 2.x a asi by melo i pro EJB 3.x):
- Hibernate je designovany pro request/response pouziti na webu, vse
jine znamena jeho znacne ohybani
- neni vhodny pro davkove zpracovani nad normalni session, protoze ta si
cachuje vsechny objekty, ktere ji prosli - at uz insertovane nebo
selectovane - dokud explicitne nepozadate o clean (session ma (musi mit)
silne refence na objekty)
- commit na session, ve ktere jsou tisice objektu trva dlouho - i vteriny
- pro davkove vkladani/mazani je lepsi pouzit StatelessSession - nevim
jestli je v JPA neco podobneho :-(
- pro davkove upravy je lepsi pouzit HQL DML nebo vetsi mnozstvi
kratkych session - otevreni session je "jen" ziskani connection z poolu
a nastartovani transakce
- take zvazte pouziti JDBC ;-)
- pokud pouzivate vice kratkych sessions je dobre mit cely proces
restartovatelny - tj. mit napr. compensating business transactions
Docela by mne zajimalo, jake blueprinty pro pouzivani JPA v Rich Client
Aplikacich, uverejni Sun v souvislosti s umistenim JPA do JRE 7 (JDK).
Lukas
