JBoss EAP 6.x comprendere la fase di implementazione - ResourceAdapters, EJB, jar, war

Question

In JBoss, qual è la sequenza della fase di distribuzione ? Qual è l'ordine di oggetti istanziati e disponibili per l'uso? Considerando un'applicazione aziendale (* .ear), ispezionando tutto registro di distribuzione (server.log) la fase di distribuzione si presenta come:

1. Tutti librerie vedono schierate - file .class vengono caricati e disponibili;
2. Tutti i moduli * .jar sono distribuiti - i file di classe sono caricati e disponibili;
3. Se alcuni * .jar è un vaso EJB, attraverso i file di configurazione o annotazioni, si crea l'albero JNDI (Ex ejb-jar.xml.);
4. Se alcuni * .jar hanno una configurazione di file persistence.xml, vengono caricate tutte le entità e il collegamento alle origini dati;
5. Tutti * .war moduli iniziano la fase di schieramento;
6. Attraverso i file di configurazione (web.xml), ascoltatori e root di contesto sono caricati ed eventualmente aspetti di sicurezza.
7. Orecchio distribuito correttamente.

Domande:

• Che dire dei moduli adattatori di risorse, il PersistenceContext e EJB Pool?
• Quando viene trovato un persistence.xml, viene avviata una connessione all'origine dati e quindi al pool DB?
• Poiché l'origine dati (DB) è configurata in standalone.xml o domain.xml, quando si verifica la prima connessione al pool di DB? Quando iniettare PersistenceContext e utilizzare EntityManager?
• Quando il pool EJB è caricato e disponibile per l'uso?
• È corretto dire che durante la distribuzione del bean EJB, la struttura JNDI viene creata e quindi disponibile?
• Quando viene rilevato un EJB, viene caricato all'interno del pool (come riferimento per iniettare/cercare)?

Quando un modulo .war viene distribuito e pronta, anche se la piena implementazione del .ear non è ancora completata, eventualmente servlet o ascoltatore vengono avviati dal contenitore.

• Cosa succede se alcuni di questi oggetti (ascoltatore, servlet) tenta di utilizzare EJB o PersistenceContext o altri oggetti? Questi oggetti sono disponibili?
• È possibile avere un problema di deadlock e bloccare il thread/fase di distribuzione?

Answer 1

• È possibile control the deployment order di vasi e guerre application.xml utilizzando <initialize-in-order>true</initialize-in-order>
• Il lifecycle of the resource adapters è controllato dal connector architecture
• Il lifecycle of Container-Managed Entity Managers sono gestiti da JBoss. Supponendo che si stia iniettando in un EJB utilizzando @PersistenceContext, ciò accade prima di @PostConstruct.
• Singleton EJB ordine di inizializzazione può essere definita utilizzando @DependsOn("OtherBean")
• è possibile garantire gli endpoint EJB sono disponibili utilizzando l'ordine distribuzione nel primo proiettile
• Non sono sicuro se è possibile dead lock - è molto più probabile che si vedrà un'eccezione JNDI

Answer 2

cercherò di affrontare il resto delle vostre domande:

Quando un persistence.xml viene trovato, fa un collegamento con la dat a-source e così all'avvio del pool di DB?

Sì, che deve accadere (se nessun collegamento già è fatto), altrimenti non la struttura della tabella (DDL) potrebbe essere validated o essere creato.

Poiché l'origine dati (DB) è configurato nel standalone.xml o domain.xml, quando avviene la prima connessione al pool DB? Quando I iniettare PersistenceContext e utilizzare EntityManager?

La risposta a questa domanda è: dipende. Se l'origine dati JDBC è configurata con una dimensione minima del pool MIN_POOL_SIZE> 0 e il flag prefill è impostato su true, allora WildFly creerà le connessioni MIN_POOL_SIZE al server DB, senza alcuna distribuzione che utilizzi quell'origine dati (dopo aver modificato tale flag sarà bisogno di disabilitare/abilitare l'origine dati). Altrimenti sulla distribuzione: viene creato il numero di connessioni necessarie (a seconda di ciò che si fa sulla distribuzione, ma per le applicazioni semplici una sola), eccetto che si ha uno 0 MIN_POOL_SIZE> 0 e il flag minimo assoluto è impostato su true, in cui caso ALMENO MIN_POOL_SIZE verranno create connessioni.

Quando il pool EJB è caricato e disponibile per l'uso?

È disponibile per l'uso dopo aver distribuito il modulo EJB, con tutte le sue dipendenze.

È corretto dire che durante la distribuzione del bean EJB, la struttura JNDI viene creata e quindi disponibile?

formulerei che nel modo seguente: Dopo (non durante) viene verificato che tutti i bean possono essere implementate (ad esempio tutti i loro dipendenze potrebbero essere risolti), quindi si creano voci JNDI (nel JNDI albero). Secondo quanto ho notato, se un singolo EJB fallisce, non viene distribuito nulla, il che mi fa pensare che sono proprio qui.

[Quando un modulo viene distribuito .war] Cosa succede se alcuni di questi oggetti (ascoltatore, servlet) tenta di utilizzare EJB o PersistenceContext o altri oggetti? Questi oggetti sono disponibili?

Sì, sicuramente. Usiamo questa funzione per eseguire alcuni codici di init da un servlet, quando il file WAR viene distribuito (ad esempio per creare alcune entità con alcuni valori predefiniti).

È possibile che si verifichi un problema di deadlock e blocchi il thread di distribuzione/fase?

Teoricamente sì, praticamente no (dubito che i ragazzi di RedHat non ci abbiano pensato).

---

Alcuni consigli: se si utilizza MySQL, è possibile controllare quali collegamenti vengono effettuati al server con show processlist. In caso contrario, se si utilizza Linux/Unix, è possibile verificare tutte le connessioni effettuate sul server DB con netstat.