Timeout SQL Persistence - Not seeing data in DB

1

Hello,

Two part question regarding Saga Timeouts and SQL Persistence.

  1. I can’t seem to get the Timeouts table to be created on startup of the process. It will generate Saga tables, and the Timeout scripts have been generated. However, no tables get generated. I’ve tried setting SQLPersistence for all tables, and even specified the Timeouts but to no avail. I’m not sure if there’s something else I’m missing. I’ve tried the following code:

     			var persistence = endpointConfiguration.UsePersistence<SqlPersistence>();
 			persistence.SqlDialect<SqlDialect.MsSqlServer>().Schema("Saga");
 			persistence.ConnectionBuilder(() =>
 			{
 				return new SqlConnection(sqlSettings.ConnectionStrings[SqlDbTypes.Saga]);
 			});
 			var timeouts = persistence.TimeoutSettings();
 			timeouts.ConnectionBuilder(
 				connectionBuilder: () =>
 				{
 					return new SqlConnection(sqlSettings.ConnectionStrings[SqlDbTypes.Saga]);
 				});

I’ve also tried this:

				var timeoutPersistence = endpointConfiguration
					.UsePersistence<SqlPersistence, StorageType.Timeouts>();
				timeoutPersistence.SqlDialect<SqlDialect.MsSqlServer>().Schema("Saga");
				timeoutPersistence.ConnectionBuilder(() =>
				{
					return new SqlConnection(sqlSettings.ConnectionStrings[SqlDbTypes.Saga]);
				});
  1. So to forge ahead, I just ran the scripts on the DB. And though the timeouts work (even with start and restarting the process) I see nothing in the Timeouts table in the DB. Will I be able to see the Timeout data in the DB? Or am I missing something simple, if you have any advice it’s much appreciated, thanks!!
2

Hi @rcountryman

What transport do you use? Some transport handle timeouts by themselves and in that case the timeout persistence is not initialized (as it is not needed).

Szymon

3

@SzymonPobiega thanks for the reply. In this case I was just using the learning transport, in deployed environments we use RabbitMQ. It appears that in both cases the timeouts are handled with the delay queues. The main worry was that it was being handled in memory and it could be lost. Just curious, does the transport have to be configured not to handle timeouts for NServiceBus to handle it via another mechanism like SQL?

4

Hey

In most cases a given transport either handles timeouts or not and there is no configuration necessary. If it does not, it requires NSB persistence to be configured (and if it is not configured, you’ll get an exception).If it does support timeouts then NSB timeout persistence, even though it might be configured, won’t be initialized.

That said, there are “transition” versions of some transports that require you to opt-in to native handling of timeouts (or opt-out if you prefer persistence based). SQL Server transport is one example.

If a given transport (like RabbitMQ) used to require timeout persistence but now has support for native timeouts, there is an option to continue using the persistence for already created timeouts so you can upgrade the transport in the middle of the lifetime of an endpoint and timeouts that have already been created but not yet triggered don’t have to be migrated.