[Hibernate] waar zit mijn flush?

[zneek]

Ik heb de volgende code:

Java:

public void saveOrUpdate(final Entity entity) throws DataAccessException {

  TransactionTemplate template = new TransactionTemplate(transManager);
  template.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);
  template.execute(new TransactionCallback() {
      public Object doInTransaction(TransactionStatus transactionStatus) {
          getHibernateTemplate().saveOrUpdate(entity);
          return null;
      }
  });
}

De bedoeling is uiteraard dat een bepaalde entity opgeslagen wordt. Dit werkt naar behoren. Maar, ik snap even niet waar mijn session nu geflushed wordt? Ik gebruik een OpenSessionInViewFilter, die standaard de sessie niet flusht. Kennelijk is er iets anders wat de sessie flusht. Dat kan op meerdere manieren, en de meest logische in dit geval is dat de template.execute aanroep een transaction.commit() aanroept, die op zijn beurt weer een session.flush aanroept. Ik kan echter nergens in de documentatie terugvinden dat dat het geval is. Weet iemand dit toevallig? Doet template.execute een commit op de transactie?

[edit] transManager is uiteraard een HibernateTransactionManager

[ Voor 3% gewijzigd door zneek op 20-07-2006 17:07 ]

[-FoX-]

Hoe staat je FlushMode ingesteld? Default is dit FlushMode.AUTO

[zneek]

-FoX- schreef op donderdag 20 juli 2006 @ 17:56:
Hoe staat je FlushMode ingesteld? Default is dit FlushMode.AUTO

De sessie komt hier uit: org.springframework.orm.hibernate.support.OpenSessionInViewFilter
Daar heb ik niets voor ingesteld, parameterloze definitie in mijn web.xml. De documentatie zegt:

NOTE: This filter will by default not flush the Hibernate Session, as it assumes to be used in combination with service layer transactions that care for the flushing, or HibernateAccessors with flushMode FLUSH_EAGER. If you want this filter to flush after completed request processing, override closeSession and invoke flush on the Session before closing it. Additionally, you will also need to override getSession() to return a Session in a flush mode other than the default FlushMode.NEVER. Note that getSession and closeSession will just be invoked in single session mode!

van http://static.springframe...nSessionInViewFilter.html

Dus moet er iets anders zijn wat alsnog een flush tot gevolg heeft.

[Cuball]

je antwoord op je vraag staat toch al in die javadoc comment?

as it assumes to be used in combination with service layer transactions that care for the flushing,

[zneek]

Cuball schreef op donderdag 20 juli 2006 @ 20:17:
je antwoord op je vraag staat toch al in die javadoc comment?


[...]

Nee, jij herhaalt een deel van mijn vraag.

Mijn vraag is wat die template.execute doet. Geeft die een transaction commit, en dus een flush? Ik kan dat niet terug vinden in de Spring documentatie, maar ik vermoed van wel.

[ Voor 8% gewijzigd door zneek op 20-07-2006 23:07 ]

[momania]

die template doet idd de commit... dat is je link naar een transactie manager waarin je de update uitvoerd

[zneek]

momania schreef op donderdag 20 juli 2006 @ 23:11:
die template doet idd de commit... dat is je link naar een transactie manager waarin je de update uitvoerd

Ah. Hoe weet je dit? Zelf uitgedokterd? Of heb ik ergens een stuk documentatie gemist?

[momania]

zneek schreef op donderdag 20 juli 2006 @ 23:24:
[...]


Ah. Hoe weet je dit? Zelf uitgedokterd? Of heb ik ergens een stuk documentatie gemist?

Nou, dat doet de transactie interface van spring voor je

[edit]
uit de docs:

quote: http://www.springframewor.../TransactionTemplate.html

It handles the transaction lifecycle and possible exceptions such that neither the TransactionCallback implementation nor the calling code needs to explicitly handle transactions.

dwz: hij doet of een commit voor je, of een rollback in geval van een unchecked exception

[ Voor 45% gewijzigd door momania op 20-07-2006 23:34 ]

[zneek]

momania schreef op donderdag 20 juli 2006 @ 23:26:
[...]

Nou, dat doet de transactie interface van spring voor je

Dat geloof ik. Ik baal er alleen zo van dat ik het nergens bevestigd kan krijgen. Dat ze het niet voor elkaar krijgen in de documentatie te vertellen wat sommige dingen nu precies doen.

[momania]

zneek schreef op donderdag 20 juli 2006 @ 23:32:
[...]


Dat geloof ik. Ik baal er alleen zo van dat ik het nergens bevestigd kan krijgen. Dat ze het niet voor elkaar krijgen in de documentatie te vertellen wat sommige dingen nu precies doen.

zie edit ^^^

[zneek]

momania schreef op donderdag 20 juli 2006 @ 23:36:
[...]

zie edit ^^^

* zneek bukt

niet te hard aub momania

Dat stuk heb ik vanmiddag echt wel 3 keer gelezen. Of beter gezegd, gezien naar niet gelezen.

[Cuball]

zneek schreef op donderdag 20 juli 2006 @ 23:32:
[...]


Dat geloof ik. Ik baal er alleen zo van dat ik het nergens bevestigd kan krijgen. Dat ze het niet voor elkaar krijgen in de documentatie te vertellen wat sommige dingen nu precies doen.

met een debugger door de code lopen kan ook al veel verduidelijken van wat er allemaal gaande is