users@glassfish.java.net

Re: Delivery of JMS message in case of distributed transaction

From: Linda Schneider <Linda.Schneider_at_Sun.COM>
Date: Thu, 18 Jun 2009 17:43:54 -0700

Conceptually I understand your problem is caused because the JMS update
is faster than the database update, but I don't know of anyone in the
real world who is having a similar issue.

Actually, I'm not 100% sure why you are ever seeing this issue ..

Are you *always* performing the database operation first ??? (you have
to if you want to guarantee the right behavior)

Are you running in a transaction ??? (not required, although it may help
to pinpoint an issue)

Here is my confusion .... I can see two possible ways to do this ...

    - Run outside of a transaction:
           - update the table (should happen before the request returns
since its not transacted)
          - send the JMS messages [which will arrive after the table is
updated since the update was done before it was sent]

   - Run inside of a transaction:
       - updating a database table
       - sending a JMS message
       - prepare for database then JMS message run (XA only)
       - commit for database run (database updated)
       - commit for JMS runs (and message is then sent, this occurs
AFTER the database has committed)

Obviously, in both cases the messages are processed in order. (unless
somehow the order for the commits does not match what I'd expect)

Can you give me more information about the order you are doing
processing and transaction type ??

-- Linda


glassfish_at_javadesktop.org wrote:
> I have a general question about distributed transactions, and how other people deal with them in the real world.
>
> We use in our of our project an Oracle database plus a few JMS queues. We have SLSB in charge to insert some data into the database then send a JMS for asynchronous processing.
>
> This works fine, but we have realized that sometimes the message is delivered before the changes in database were committed. This means that we sometimes read stale data, which is a serious issue. Our workaround is to lock the row before reading (or use "select ... for update") so that the message processing will wait until the original transaction is completed.
>
> This seems to me like a basic scenario and I guess that other people also faced a similar problem. I'm wondering how other people solved this issue?
> [Message sent by forum member 'ewernli' (ewernli)]
>
> http://forums.java.net/jive/thread.jspa?messageID=351867
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>