Archief - [PROG][JAVA] Spring + Hibernate: overbodig SELECT statement

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
f

forloRn_

Legacy Member
Goeiemiddag,

Mijn DAO maakt gebruik van een Spring HibernateTemplate. Voor het toevoegen van meerdere Transactions aan mijn tabel gebruik ik de volgende method:

Code: 
	public void saveTransactions(Collection<Transaction> transactions) {
		getHibernateTemplate().saveOrUpdateAll(transactions);
	}

De queries die Hibernate generereert voor een collection van drie Transactions is de volgende:

Code: 
Hibernate: insert into TRANSACTIONS (PROVIDERID, MAC, EVENTID, PRICE, TIMESTAMP, SELECTIONID, TEXTSTRING, EXPORTEDFORPOSTPROCESSING, EXPORTEDFORBILLING, TRANSACTIONID) values (?, ?, ?, ?, ?, ?, ?, ?, ?, null)
Hibernate: call identity()
Hibernate: insert into TRANSACTIONS (PROVIDERID, MAC, EVENTID, PRICE, TIMESTAMP, SELECTIONID, TEXTSTRING, EXPORTEDFORPOSTPROCESSING, EXPORTEDFORBILLING, TRANSACTIONID) values (?, ?, ?, ?, ?, ?, ?, ?, ?, null)
Hibernate: call identity()
Hibernate: insert into TRANSACTIONS (PROVIDERID, MAC, EVENTID, PRICE, TIMESTAMP, SELECTIONID, TEXTSTRING, EXPORTEDFORPOSTPROCESSING, EXPORTEDFORBILLING, TRANSACTIONID) values (?, ?, ?, ?, ?, ?, ?, ?, ?, null)
Hibernate: call identity()
Hibernate: select transactio0_.TRANSACTIONID as TRANSACT1_0_, transactio0_.PROVIDERID as PROVIDERID0_, transactio0_.MAC as MAC0_, transactio0_.EVENTID as EVENTID0_, transactio0_.PRICE as PRICE0_, transactio0_.TIMESTAMP as TIMESTAMP0_, transactio0_.SELECTIONID as SELECTIO7_0_, transactio0_.TEXTSTRING as TEXTSTRING0_, transactio0_.EXPORTEDFORPOSTPROCESSING as EXPORTED9_0_, transactio0_.EXPORTEDFORBILLING as EXPORTE10_0_ from TRANSACTIONS transactio0_

Ik neem aan dat Hibernate dat SELECT statement genereert om de overeenkomstige POJO's up-to-date te houden. Stel dat ik nu na de INSERT niet meer geïnteresseerd ben in die Transactions, dan heeft het ook geen zin dat ze weer geüpdatet worden. Hoe voorkom ik dat Hibernate die SELECT uitvoert?
B

Bavo aka Joske

Legacy Member
Hibernate wil inderdaad de POJO's synchroniseren, in dit geval lijkt hij ervoor te willen zorgen dat het ID veld ingevuld is in de POJO. Dat ID veld wordt erg waarschijnlijk door de DB zelf bepaald, en is niet gekend tijdens de save, en nodig om later uw POJO goed te identificeren met de persistente vorm.

Ik zie niet meteen een wijze om dat te vermijden in de API (je kijkt dan wel beter naar pure Hibernate ipv een Spring wrapper), wat wel mogelijk is is uw Object ID door Hibernate laten genereren, zodat ie het zelf kan invullen zonder de DB te consulteren. Zie http://www.hibernate.org/hib_docs/reference/en/html/mapping.html#mapping-declaration-id

Het is niet gegerandeerd dat dat de zaak oplost.

Zijn die selects nefast?
f

forloRn_

Legacy Member
Bavo aka Joske zei:
Hibernate wil inderdaad de POJO's synchroniseren, in dit geval lijkt hij ervoor te willen zorgen dat het ID veld ingevuld is in de POJO. Dat ID veld wordt erg waarschijnlijk door de DB zelf bepaald, en is niet gekend tijdens de save, en nodig om later uw POJO goed te identificeren met de persistente vorm.
Klik om te vergroten...

Klopt. Die ID's worden bepaald door een sequence in een Oracle DB of een identity in een Hypersonic DB.

Bavo aka Joske zei:
Zijn die selects nefast?
Klik om te vergroten...

Ja. Het streefdoel is duizend INSERTs per seconde. Gewone JDBC die een INSERT doet zonder meer is pakweg vijftien keer zo snel.
B

Bavo aka Joske

Legacy Member
Als snelheid uw streefdoel is, overweeg je beter zuivere SQL ipv mapping. Zoals je zegt werkt JDBC beter daarvoor, het is geen slechte zaak uw DAO met zo een implementatie te laten werken zuiver voor performante inserts.

Een andere mogelijkheid is bufferen en batchen, aangezien de select blijkbaar intelligent gebeurt na een reeks, en niet na elke insert.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan