Dovrebbero tavoli jBPM essere in database separato?

Question

Ci sono due opzioni quando si imposta la sessione JBPM.

1. È possibile inserire le mappature jBPM nella stessa sessione Hibernate, e, di conseguenza, hanno le loro tabelle del database con le tabelle applicazioni.

2. È possibile inserire le mappature jBPM in una sessione Hibernate separata, e li hanno in un database separato.

Ho visto un articolo che suggerisce il metodo 1, e posso capire perché, perché ti permette di avere i riferimenti di chiave esterna per gli oggetti direttamente i dati JBPM. L'unico problema che ho visto pop up è se si cerca di salvare l'oggetto jBPM mentre un processo è in esecuzione JBPM, si ottiene una situazione di stallo nel database.

Oltre a questo, quale metodo sarebbe meglio, e per quali motivi?

Answer 1

Dipende l'architettura si vuole costruire.

Se si desidera un componente del flusso di lavoro gestito centralmente, dove diverse applicazioni comunicano con un unico database è la strada da percorrere.

Otoh, se il flusso di lavoro è specifica solo per alcune applicazioni, è meglio mantenere i database separati. In questo modo, è possibile aggiornare jBPM più avanti in alcune applicazioni e lasciare così com'è in altri.

Ma si può anche decidere di avere un DB separato per ogni applicazione, anche se ci sono un sacco. In questo modo, la performance di runtime rimane grande dal momento che non c'è un tavolo enorme da gestire)

Come si può vedere, jBPM è molto flessibile nel modo di integrarlo in un architettura. Quindi sarà necessario per rendere l'analisi per te stesso e decidere qual è l'approccio migliore, tenuto conto corrente e future evoluzioni della vostra architettura.

Answer 2

Mettere entrambe le tabelle di applicazione e jBPM in 1 banca dati consente di aggiornare entrambe le tabelle jBPM ed i vostri dati delle applicazioni in una singola transazione. Questo è utile se, ad esempio, si desidera aggiornare qualche attributo sul tuo dati delle applicazioni quando un compito viene eseguita in jBPM. Questo aiuta a mantenere i dati da venire corrotto. In caso contrario, se si impegnano la transazione jBPM e poi esegue in un problema di commettere la transazione di dati di applicazione, si ha un bel grosso problema ...

Answer 3

Abbiamo avuto un caso in cui abbiamo deciso di mantenere il database jBPM separata in modo da essere in grado di aggiornare la versione o magari utilizzare un altro fornitore, quando sarebbe stato necessario per diversi clienti. Come accennato in precedenza, ci siamo imbattuti in situazioni in cui abbiamo avuto a che fare con le sessioni Hibernate separate per una singola operazione nel livello di applicazione. Al fine di mantenere la coerenza in quelle condizioni, abbiamo deciso di utilizzare uno strumento chiamato Atomikos