Return-Path: X-Original-To: apmail-activemq-dev-archive@www.apache.org Delivered-To: apmail-activemq-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5089BE3CA for ; Wed, 20 Feb 2013 15:45:20 +0000 (UTC) Received: (qmail 33109 invoked by uid 500); 20 Feb 2013 15:45:19 -0000 Delivered-To: apmail-activemq-dev-archive@activemq.apache.org Received: (qmail 32778 invoked by uid 500); 20 Feb 2013 15:45:15 -0000 Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@activemq.apache.org Delivered-To: mailing list dev@activemq.apache.org Received: (qmail 32030 invoked by uid 99); 20 Feb 2013 15:45:14 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 Feb 2013 15:45:14 +0000 Date: Wed, 20 Feb 2013 15:45:14 +0000 (UTC) From: "Timothy Bish (JIRA)" To: dev@activemq.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (AMQ-4337) Messages with AMQ_SCHEDULED_DELAY do not respect transactions MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/AMQ-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated AMQ-4337: ------------------------------ Priority: Minor (was: Major) > Messages with AMQ_SCHEDULED_DELAY do not respect transactions > ------------------------------------------------------------- > > Key: AMQ-4337 > URL: https://issues.apache.org/jira/browse/AMQ-4337 > Project: ActiveMQ > Issue Type: Improvement > Reporter: Remo Gloor > Priority: Minor > > Currently delayed messages are delivered even if the session it was sent in is rolled back. According to http://activemq.2283324.n4.nabble.com/AMQ-SCHEDULED-DELAY-and-transactional-boundaries-td4658339.html this is because the message can be delivered far in the future and the transaction would take to long. > I don't agree with that argument. The transaction can be short living. It is only the enqueuing of the delayed message in the broker that has to be part of the transaction. The delivery to the consumer is not part of the transaction anymore. > e.g. consider the scenario in the following preudo code: > while (application_runs) > try{ > msg = session.Receive(); > session.SendDelayed(anotherMessage); > if (random(5) != 0) throw exception; > session.Commit(); > } catch { session.Rollback; } > Currently a delayed message is sent for each retry. So we will get a lot more messages in the future as we would expect. When delayed messages would respect transactions just the successful ones would be enqueued. The other ones are rolledback with the transaction. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira