In that case I would suggest installing and configuring a X/Open Distributed Transaction Processor
such as Oracle's Transaction Process Manager to quote
"<the TPM> uses Oracle XA library subroutines to tell Oracle Database how to process
the transaction, based on its knowledge of all RMs in the transaction."
Oracle handles the coordination from multiple registering requesting entities as Resource Managers to TPM
the TPM Transaction Manager coordinates request activity to all RMs by either committing or rolling back all
Transaction requests from RM participants
http://stanford.edu/dept/itss/docs/oracle/10g/appdev.101/b10795/adfns_xa.htm#1015699
HTH
Martin
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
> Date: Fri, 19 Jun 2009 01:16:46 -0700
> From: glassfish_at_javadesktop.org
> To: users_at_glassfish.dev.java.net
> Subject: Re: Delivery of JMS message in case of distributed transaction
>
> Thanks for your feedback.
>
> The EJB that updates the database and sends the message is running within a distributed transaction. From the bean point of view the transactional semantics is ok: the database update and the message sending are committed or rolled back together when the transaction completes. No message is ever delivered if transaction is rolled back.
>
> We first update the database then send the JMS message. We are using JPA to load and update the entity in database, so it's hard to say when the database changes are actually flushed, and if it impacts the order of events in the 2 phase commit protocol.
>
> At a point in time, there are two participants enlisted in the transaction manager (the database connection and the JMS queue, both XAResource). I don't know how the transaction manager decides the order of the prepare/commit sequence. The transaction manager doesn't know the nature of the participants and doesn't know what operations were performed on each participant. From my understanding the order shouldn't matter and it could be either database-JMS or JMS-database.
>
> Unfortunately, if it turns out that the transaction manager commits first the JMS then the database, the message [i]may[/i] be delivered before the database changes are done.
>
> The problem is reproducible, but not systematic. This could be explained either because of the delivery delay, or because the order in the 2 phase commit is not deterministic.
> [Message sent by forum member 'ewernli' (ewernli)]
>
> http://forums.java.net/jive/thread.jspa?messageID=352031
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
_________________________________________________________________
Hotmail® has ever-growing storage! Don’t worry about storage limits.
http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage_062009