Ho visto la spring.jpa.open-in-view=trueproprietà nella documentazione di Spring Boot per la configurazione JPA.
truevalore predefinito per questa proprietà se non è fornito affatto ?;SessionFactoryinvece di EntityManagerFactory? Se sì, come posso dirgli di consentirmi di usarlo EntityManagerFactoryinvece?Grazie!
Risposte:
Questa proprietà registrerà un OpenEntityManagerInViewInterceptor, che registra un EntityManageral thread corrente, quindi avrai lo stesso EntityManagerfino al termine della richiesta web. Non ha nulla a che fare con Hibernate SessionFactoryecc.
Invece di lasciare che il livello aziendale decida come è meglio recuperare tutte le associazioni necessarie dal livello di visualizzazione, OSIV (Open Session in View) forza il contesto di persistenza a rimanere aperto in modo che il livello di visualizzazione possa attivare l'inizializzazione del proxy, come illustrato dal diagramma seguente.
OpenSessionInViewFilterchiama il openSessionmetodo del sottostante SessionFactorye ottiene una nuova Session.Sessionè legato al TransactionSynchronizationManager.OpenSessionInViewFilterchiamate doFilterdel javax.servlet.FilterChainriferimento all'oggetto e la richiesta viene ulteriormente elaborataDispatcherServletsi chiama, e instrada la richiesta HTTP al sottostante PostController.PostControllerchiamate i PostServiceper ottenere una lista di Postentità.PostServiceapre una nuova transazione, e lo HibernateTransactionManagerriutilizza lo stesso Sessionche è stato aperto dal OpenSessionInViewFilter.PostDAOrecupera l'elenco delle Postentità senza inizializzare alcuna associazione pigra.PostServicecommit della transazione sottostante, ma Sessionnon è chiuso perché è stato aperto esternamente.DispatcherServletpartenze di rendering dell'interfaccia utente, che, a sua volta, naviga le associazioni pigri e fa scattare la loro inizializzazione.OpenSessionInViewFiltergrado di chiudere la Session, e la connessione al database sottostante è rilasciato come pure.A prima vista, questa potrebbe non sembrare una cosa terribile da fare, ma, una volta visualizzata dalla prospettiva di un database, una serie di difetti iniziano a diventare più evidenti.
Il livello di servizio apre e chiude una transazione di database, ma in seguito non è in corso alcuna transazione esplicita. Per questo motivo, ogni istruzione aggiuntiva emessa dalla fase di rendering dell'interfaccia utente viene eseguita in modalità di commit automatico. Il commit automatico mette sotto pressione il server del database perché ogni istruzione deve scaricare il log delle transazioni su disco, causando quindi molto traffico di I / O sul lato database. Un'ottimizzazione sarebbe contrassegnare Connectioncome di sola lettura, il che consentirebbe al server di database di evitare la scrittura nel log delle transazioni.
Non c'è più separazione delle preoccupazioni perché le istruzioni vengono generate sia dal livello di servizio che dal processo di rendering dell'interfaccia utente. La scrittura di test di integrazione che affermano il numero di istruzioni generate richiede il passaggio a tutti i livelli (Web, servizio, DAO) mentre l'applicazione viene distribuita su un contenitore Web. Anche quando si utilizza un database in memoria (ad esempio HSQLDB) e un server web leggero (ad esempio Jetty), questi test di integrazione saranno più lenti da eseguire rispetto a se i livelli fossero separati e i test di integrazione back-end usassero il database, mentre il i test di integrazione front-end deridevano del tutto il livello di servizio.
Il livello dell'interfaccia utente è limitato alla navigazione nelle associazioni che possono, a loro volta, attivare N + 1 problemi di query . Sebbene Hibernate offra il @BatchSizerecupero di associazioni in batch e FetchMode.SUBSELECTper far fronte a questo scenario, le annotazioni influenzano il piano di recupero predefinito, quindi vengono applicate a ogni caso d'uso aziendale. Per questo motivo, una query del livello di accesso ai dati è molto più adatta perché può essere adattata ai requisiti di recupero dei dati del caso d'uso corrente.
Ultimo ma non meno importante, la connessione al database viene mantenuta per tutta la fase di rendering dell'interfaccia utente, il che aumenta il tempo di lease della connessione e limita il throughput complessivo della transazione a causa della congestione nel pool di connessioni del database. Più la connessione viene mantenuta, più altre richieste simultanee attenderanno per ottenere una connessione dal pool.
Sfortunatamente, OSIV (Open Session in View) è abilitato per impostazione predefinita in Spring Boot e OSIV è davvero una cattiva idea dal punto di vista delle prestazioni e della scalabilità .
Quindi, assicurati application.propertiesdi avere la seguente voce nel file di configurazione:
spring.jpa.open-in-view=falseQuesto disabiliterà OSIV in modo che tu possa gestirlo nel LazyInitializationExceptionmodo giusto .
A partire dalla versione 2.0, Spring Boot emette un avviso quando OSIV è abilitato per impostazione predefinita, quindi è possibile scoprire questo problema molto prima che influisca su un sistema di produzione.
Per maggiori dettagli su OSIV, consulta questo articolo .