È corretto utilizzare DataSourceTransactionManager per la persistenza ORM anziché HibernateTransactionManager?

Question

Sto eseguendo il debug della nostra webapp. È configurato per creare un bean DataSourceTransactionManager e anche un bean HibernateTransactionManager all'avvio. Questo non è intenzionale ma è causato da una dipendenza di terze parti. L'effetto sembra essere benigno. Quello che vedo tramite il debugging è che quando persistiamo un oggetto tramite un DAO basato su Hibernate, viene richiamato il DataSourceTransactionManager e non l'HibernateTransactionManager (entrambi i bean sono chiamati 'transactionManager'). Il Javadoc di Primavera implica (penso, rileggendolo ora) questo va bene per le risorse locali - che è la nostra situazione. Cioè non è un ambiente basato su JTA distribuito.

La mia domanda è: c'è qualche impatto negativo sul non utilizzo di HibernateTransactionManager per la persistenza basata su ORM. Posso modificare la configurazione per utilizzare HibernateTransactionManager tramite un qualificatore sull'annotazione @Transactional sui nostri DAO.

Le cose stanno funzionando bene con semplici test di unità, setup di test di integrazione, ma sono più preoccupato di ridimensionare a volumi di produzione completi quando avremo migliaia di utenti e un alto livello di concorrenza.

TIA, sperare che questo non sia troppo oscuro.

Spring 3.0.x BTW.

Questo è nei documenti Spring 3.1.

Sec 11,9 "Soluzioni a problemi comuni".

Utilizzare l'implementazione PlatformTransactionManager corretta basata su la scelta di tecnologie e requisiti transazionali.

Answer 1

Questo mi sembrerebbe sbagliato e causerebbe problemi. Senza il gestore txn di ibernazione, tutte le chiamate fatte a HibernateOperations saranno al di fuori di una transazione e in una sessione separata, possibilmente utilizzando il commit automatico. Quindi potrebbe sembrare che tutto vada bene quando si verifica un errore, potresti non trovare modifiche che ti aspetteresti di essere sottoposti a roll-back.

provare il seguente per verificare

• cominciano tran
• salvare qualcosa
• eccezione tiro
• commettere

Controllare se il 'qualcosa' compare nel DB o meno.

Un'altra verifica sarebbe

• iniziare tran
• carico qualcosa
• accesso una relazione a un altro oggetto da qualcosa e accedere a una proprietà (non il pk) di questo oggetto correlato

L'ultima chiamata può causare un'eccezione poiché la sessione non è stata mantenuta aperta dal carico in quanto il txn di inclusione non è gestito dal gestore txn di ibernazione.