La consegna di messaggi JMS prima del commit della transazione

Question

Ho un semplice scenario che coinvolge un database e un JMS in un'applicazione server (Glassfish).Lo scenario è estremamente semplice:

1. an EJB inserts a row in the database and sends a message.
2. when the message is delivered with an MDB, the row is read and updated. 

Il problema è che a volte l' il messaggio viene recapitato prima che l'inserto è stato commesso nel database.Questo in realtà è comprensibile se si considera il protocollo di commit a 2 fasi:

1. prepare JMS
2. prepare database
3. commit JMS
4. ( tiny little gap where message can be delivered before insert has been committed)
5. commit database

Ho discusso di questo problema con gli altri, ma la risposta era sempre: "Strano, dovrebbe funzionare out of the box".

Le mie domande sono quindi:

• Come potrebbe work out-of-the-box?
• Il mio scenario suoni abbastanza semplice, perché non ci sono più persone con problemi simili?
• Sto facendo qualcosa di sbagliato?C'è un modo per risolvere questo problema in modo corretto?

---

Qui sono un po ' più particolari circa la mia comprensione del problema:

Questo problema di temporizzazione esistere solo se il partecipante vengono trattati in questo ordine.Se 2PC tratta partecipanti in ordine inverso (database prima poi message broker) che dovrebbe andare bene.Il problema era casualmente succede, ma completamente riproducibile.

Non ho trovato nessun modo per controllare l'ordine dei partecipanti alle transazioni distribuite in JTA, JCA e APP specifiche né in Glassfish documentazione.Si può presumere che sarà integrata nella transazione distribuita secondo l'ordine quando vengono utilizzati, ma con un ORM come JPA, è difficile sapere quando i dati vengono scaricati e quando la connessione al database è molto utilizzato.Qualche idea?

Answer 1

Si sta verificando il classico XA 2-PC race condition.Accade in ambienti di produzione.

Ci sono 3 cose che possono venire in mente.

1. L'ultimo agente di ottimizzazione in cui JDBC è il non-XA risorsa.(Perdere di recupero semantica)
2. Sono JMS Tempo Per la consegna.(Volutamente Perdere tempo reale)
3. Costruire tentativi nel JDBC codice.(Meno effetto sulla funzionalità)

Weblogic ha questo LLR ottimizzazione evita questo problema e ti dà tutti XA garanzie.