That's quite bad that RSB cannot do transactional processing correctly. Fine if you can live with that but imho it should be safe by default. And imho 10 minutes is way too long for a single transaction, especially a distributed transaction. If your processing takes so long you should probably use some long-running task for storing intermediate status, for example a saga. And I confirm, there is a difference between SQL 2005 and 2008 in how they handle distributed transactions - in SQL 2005 you will be promoted to a distributed transaction if you open a second connection to same database inside a transaction scope. SQL 2008 will not use DTC in such case. I've been fighting with transactional processing of messages for quite a long time and have even built an SQL-only message bus just to be able to guarantee ACID without resorting to DTC. It's nice to have it working but there are many pitfalls and if you can, it's better to avoid using DTC at all.
Best regards RG On Friday, November 2, 2012 4:31:05 PM UTC+1, Daventry wrote: > > Hi Corey, > > I think I replied just to you instead of posting to the group. > > We're using Rhino Queues as transport. RSB version is 2.3.4.0 > > We're also supressing the TransactionScope because otherwise the DTC kicks > in every time we open a second connection to a DB (which is SQL Server 2008 > R2). I thought this was a SQL Server 2005 bug and should not happen in the > 2008 version... > > Thanks. > > On Friday, November 2, 2012 3:08:16 PM UTC, Corey wrote: > >> The TransactionScope timeout would be much sooner than 10 minutes. I'm >> not sure why you would be seeing this behavior. Which transport is being >> used? >> >> On Wed, Oct 31, 2012 at 11:22 AM, Daventry <[email protected]> wrote: >> >>> Hi, >>> >>> We've noticed that when our message is being processed, after 10 minutes >>> the message is processed even though the first run hasn't errored. So they >>> both run in parallel (because we have set the bus threadcount to 5). >>> If the first run finishes in less than 10 minutes, then we don't see >>> such behavior. >>> >>> We don't have this problem when threadcount is set to 1. >>> >>> Regards. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Rhino Tools Dev" group. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msg/rhino-tools-dev/-/VvCvUP1WXI8J. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/rhino-tools-dev?hl=en. >>> >> >> -- You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To view this discussion on the web visit https://groups.google.com/d/msg/rhino-tools-dev/-/WZEpY0Z1ogoJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en.
