Utilizzo di entrambe le sessioni JPA EntityManager e Hibernate con gestore transazioni condivise in primavera

Question

Abbiamo una situazione difficile.

1. C'è un progetto di grandi dimensioni che utilizza funzioni speciali di ibernazione quindi non può uscire da ibernazione.
2. Dobbiamo aggiungere il motore di processo Activiti al progetto in modalità incorporata e utilizzare le estensioni JPA (che funziona solo con EntityManager)
3. Alcune entità non dovrebbero essere presenti nell'unità persistente JPA perché come documentazione di activiti dice che tutte le entità devono avere @Id e non usare @ IdClass/@ EmbeddedId quindi dobbiamo escludere tali entità dall'unità persistente
4. Vogliamo utilizzare un gestore di transazioni condivise per EntityManager e Session. Anche i dataSource sono identici (o anche condivisi)
5. Tutto è primavera!

Tutto questo è necessario per consentire ad Activiti di utilizzare EntityManager per la sua estensione JPA lasciando che i codici dipendenti da ibernazione esistenti continuino a funzionare.

Answer 1

Prima di tutto, il terzo punto sopra può rivelarsi difficile da sistemare se si desidera avere un'unità di persistenza e in realtà si sta utilizzando @ IdClass/@ EmbeddedId nelle entità di Hibernate. Qui ci sono due possibili soluzioni:

1. Pull JPA nel tuo progetto e configurare un'unità di persistenza per le entità Hibernate esistenti, ma proseguire per delegare le chiamate esistenti per Hibernate accedendo direttamente alla sessione. In questo caso, la tua configurazione verrebbe spostata su JPA, ma il tuo codice non lo farebbe. Questo approccio presuppone anche che tu disponga di una ragionevole astrazione che distribuisce oggetti Session in modo collegabile. Vedi this question for the crux of the solution. Se hai zero flessibilità sul punto 3 sopra, questo approccio potrebbe non essere un'opzione per te.

2. Creare una factory di sessione e un'unità di persistenza e coordinare le transazioni utilizzando JTA con due origini dati XA. Anche se i tuoi dati potrebbero risiedere nello stesso database, ti consigliamo di assicurarti di creare origini dati distinte nella configurazione se segui questo approccio. Ciò impedirà che il proxy transazionale di Spring si confonda quando si partecipa alla transazione distribuita. Questo è probabilmente l'approccio più pulito, ma porta lo stigma delle transazioni XA che, a seconda del contenitore, è più un problema politico al giorno che tecnico.