Potential Problem 2PC

Question

We are using weblogic 8.1 sp4 on our Server
          Solaris 2.9
          We have a Stateless Session Bean which does the following:
          Gets a User Transaction
          Begins Transaction
               gets JDBC TX Connection
               Calls DBMS Stored Proc
               Sends Message to a queue
          Commits Transaction
          What seems to be happening is that the message is sent out before the
          commit to the dbms has occured. We noticed this when a client complained
          when they replied back to a message that the message did not exist in the
          dbms
          We are using Sybase JConnect5.5
          We are emulating 2pc on their driver
          Our Queue Connection Factory has XA Connection Factory Enabled
          Our JDBC Datasource has Emulate Two-Phase Commit for non-XA Driver
          This has occured in production 6 times within the last 5 months.
          Any help would really be appreciated.

Answer 1

Larry Presswood wrote:
          > A message comming from a sender gets committed to the dbms and then is
          > sent to the queue for a consumer. The issue is in rare cases the
          > consumer which is outside of our company gets the message and sends a
          > reply back. This goes out a comms server, a protocol conversion and
          > then out to a wan and then is sent back. This would mean that the dbms
          > is taking along time to commit however our JTA time is an average of
          > 20ms.
          >
          > We received the reply 200ms after the start of the TX so it took that
          > long? What is strange is that in development we have a very hard time
          > reproducing this problem.
          >
          > I thought 2PC gauranteed that the data is either in both resources or in
          > neither. Nothing I have read states that they will be there at
          > different times which is basically the case. Even if this is the case
          > why do you not follow the order we use in our app as we call dbms first
          > and send to queue 2nd. A simple stack would allow you to invoke commit
          > to the resources in the order we specified in our application. Also I
          > would have thought it was an error to allow the message to become
          > available in the queue until both resources had completed?
          >
          > We can't upgrade to 9.2 fast so it looks like we will need to do our own
          > LLR. It would seem to me that if LLR fixes it but JTA does not then
          > there is perhaps an issue in the implementation? I had asked our
          > support engineer if using an XA driver would improve the problem but he
          > said it might make it worse.
          >
          > What gets me is if you commit to the queue first and then the dbms fails
          > there is no way you could remove it from the queue?
          Hi. You can try the JDBC with an XA driver, but it might help or it
          might hurt, depending on how long the DBMS takes to do the commit
          anyway. (I would try it) There is one transaction that includes the
          JMS resource and the DBMS resource. There is no way for a tx coordinator
          to control how long each of these resources take to commit, and they
          may even be committed in separate threads, not serially. The only way
          to ensure that everything is where you want it, is to react only to
          the completion of the whole WLS transaction, not the immediate content
          of any of the resources as they individually complete their commits.
          If the DBMS commit fails, it is ugly in 8.1. Luckily with Sybase
          and MS SQLServer (for instances) a commit is exceedingly unlikely to
          fail at runtime (as opposed to during recovery), because the pessimistic
          locking scheme has made sure the DBMS has already gotten all the locks
          it needed for the tx. The delay may have to do with DBMS log contention...
          Joe
          >
          >
          >
          >
          >
          > Joe Weinstein <[email protected]> wrote in
          > news:[email protected]:
          >
          >
          >>Larry Presswood wrote:
          >>
          >>
          >>>Joe Weinstein <[email protected]> wrote in
          >>>news:[email protected]:
          >>>
          >>>
          >>>
          >>>>Hi Larry, This is a known issue. We can not order the commit call to
          >>>>the resources, so you need to manage it from the application. You
          >>>>should not take action based on a message being committed to a queue.
          >>>>The only other way to control this is by using our LLR transactional
          >>>>feature, but that is only available via WLS 9.x. Joe
          >>>>
          >>>
          >>>
          >>>Joe how would we control it from the application? We do call the
          >>>dbms first then put into the JMS queue but not sure what you might be
          >>>recommending here.
          >>>
          >>>Thanks
          >>>Larry
          >>
          >>Hi.
          >>Your application has some dependency on the message making it into
          >>the queue, independent of/before the record has been committed into
          >>the database so you need to change that dependency. Maybe you need
          >>to make sure the message is inserted or updated into the db before
          >>taking action about the message. Tell us more about what the
          >>application is doing.
          >
          >>