[Java lista] Prepared JPA Query

[Zsombor]

2009/8/4 Szomor Attila <aszomor at computertechnika.hu>

> Sziasztok,
>
> CSV-bol importálni kellene adott rendszerességgel különböző törzsadat
> frissĂ­tĂŠseket:
>  1, Kell egy ellenőrzés, hogy már létezik-e, ha igen update
>  2, ha nem létezett, egy másik ellenőrzés, hogy az Ő master-e létezik-e,
> ha igen felvesszĂźk
> látszőlag roppant egyszerű, két Query és egy em.persist vagy egy em.update.
> Az alap kĂłdtĂśrzsben 5000 (WHO) kĂłd van ĂŠs ehhez egy kapcsolat 282000
> (WHO_Competencia)adatot rendelne,
> ez első megközelítésben 12 órát futott ebből a CSV olvasás és parse 1.5mp
> az em.persist kb 20perc, a kĂŠt select ĂŠs a log kb. 11 Ăłra 40perc.
> A logbĂłl az lĂĄtszik, hogy a (A vagy B)Query.setParameter(1,
> whoxWhoCom.getWhoCwho()); 0.016mp minden alkalommal, most egy első
> feltĂśltĂŠsnĂŠl ez
> 282000 * 2 * 0.016mp = 9024mp az az 150.4perc.
>
> Ez Delphi-vel 4 prepared statement-el (2 select, 1 insert, 1 uopdate) nem
> egĂŠsz 3 percig tart, gondoltam, hogy egy interpretĂĄlt nyelv a kĂśzelĂŠbe sem
> ĂŠrhet, de hogy ennyire nem az gĂĄz !!!
>
> A JPA Query-kre nem találtam prepare lehetőséget, gondoltam egyet durván
> megkerĂźlĂśm az em-t aztĂĄn gyerĂźnk prepareStatement, az update kersĂŠs
> kihagyva, csak az insert-re koncentrĂĄlva 15perc, hĂĄt ez lehangolĂł !!!
>
> Hogy importĂĄltok java-bĂłl ???
>


Figyelünk arra, hogy hol kezdődik, fejeződik be a tranzakció, illetve hogy
az entity cachet, ha ilyen bulk mĂźveletek szĂźksĂŠgesek, akkor mindig ĂźrĂ­tsĂźk.
a flush vagy a clear metĂłdus segĂ­tsĂŠgĂŠvel. EnĂŠlkĂźl elĂŠg sok objektum
halmozĂłdhat fel a memĂłriĂĄban.

Zs
--------- következő rész ---------
Egy csatolt HTML ĂĄllomĂĄny ĂĄt lett konvertĂĄlva...
URL: http://javagrund.hu/pipermail/javalist/attachments/20090804/059c2678/attachment.html