ActiveMQ .Net
  1. ActiveMQ .Net
  2. AMQNET-124

Irregular Behavior When Using Commit and Rollback on Non-Transacted Queue

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.2.0
    • Fix Version/s: 1.1.0
    • Component/s: ActiveMQ
    • Labels:
      None
    • Environment:

      Windows, Latest Code from Subversion database

      Description

      If I instantiate a queue and then listen to it as non-transacted (eg not using AcknowledgementMode.Transactional), and then after processing a message call either session.Commit() or session.Rollback() I get REALLY random behavior.

      Sometimes messages don't appear. Sometimes messages appear, but they are the old messages even though within the queue it is a new message.

      I know that I should not be calling a transactional method on a non-transactional queue, but I thought an exception would be warranted.

        Activity

        Hide
        semog added a comment -

        I added several new unit tests to test calling transaction methods (Commit, Rollback) on a non-transacted session. They all throw the expected exception and appear to be functioning correctly. I am resolving this item unless a counter-example can be coded into a unit test that shows failure.

        Show
        semog added a comment - I added several new unit tests to test calling transaction methods (Commit, Rollback) on a non-transacted session. They all throw the expected exception and appear to be functioning correctly. I am resolving this item unless a counter-example can be coded into a unit test that shows failure.
        Hide
        Christian Gross added a comment -

        I can do that. Please give me a few days

        Show
        Christian Gross added a comment - I can do that. Please give me a few days
        Hide
        semog added a comment -

        Yes, an exception should definitely be thrown here. I'm surprised that it isn't.
        Could you provide a small snippet of code that exposes this behavior? If you want, you could even add it as a test case to the unit tests. Otherwise, I can add it to the test cases. I wouldn't want this to creep up again. Thanks!

        Show
        semog added a comment - Yes, an exception should definitely be thrown here. I'm surprised that it isn't. Could you provide a small snippet of code that exposes this behavior? If you want, you could even add it as a test case to the unit tests. Otherwise, I can add it to the test cases. I wouldn't want this to creep up again. Thanks!

          People

          • Assignee:
            Jim Gomes
            Reporter:
            Christian Gross
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development