Configuration Properties
The connection, connection-pool, and transaction retry/restore/streaming properties below are bound by a dialect-neutral configuration class shared across every stacksaga--reactive-support SQL module — MySQL, Oracle, PostgreSQL, and any other SQL dialect added in the future. This is why the property prefix below is stacksaga.datasource. rather than being named after any single database, and why transaction tuning is bound under stacksaga.mysql.transaction.* even when the module in use is not MySQL — the retry engine itself lives in a vendor-neutral runtime module and is not duplicated per dialect.
Setting either of these prefixes configures the behaviour for whichever SQL database support module you have added.
| Property Name | Default Value | Type | Description |
|---|---|---|---|
|
|
|
Enable or disable the starter entirely. Defaults to true so it activates automatically when added. |
The following |
|||
|
|
|
The R2DBC connection URL used by the event-store, e.g. |
|
|
|
The database server host for the reactive event-store connection. |
|
|
|
The database server port for the reactive event-store connection. Override this for non-MySQL dialects (e.g. |
|
|
|
The database/service name used by the event-store via R2DBC. |
|
|
|
The username for the event-store’s R2DBC connection. |
|
|
|
The password for the event-store’s R2DBC connection. |
|
|
|
The maximum time to wait while establishing an event-store connection to the database server. |
|
|
|
Additional R2DBC driver-specific connection options for the event-store, as key-value pairs. |
|
|
|
The number of connections to create in the event-store’s connection pool on startup. |
|
|
|
The maximum number of connections allowed in the event-store’s connection pool. |
|
|
|
The maximum time a connection may remain idle in the event-store’s pool before being closed. |
|
|
|
The maximum lifetime of a connection in the event-store’s pool before it is closed and replaced. |
|
|
|
The maximum time to wait when acquiring a connection from the event-store’s pool before failing. |
|
|
|
The query used to validate an event-store connection before it is handed out from the pool. |
The following |
|||
|
|
|
How long a transaction stays live. After this period it is no longer exposed for retry even if it is still in a processing state. |
|
|
|
How long a transaction is kept waiting before it is next exposed for retrying, to avoid retrying a transaction too frequently in a short period of time. |
|
|
|
How long a transaction may go without being updated before it is considered crashed (e.g. due to an application crash) and is restored and exposed for retrying. |
|
|
|
How many transactions are fetched from the database at once into the in-memory buffer (Reactor |
|
|
|
The buffered-transaction count at which the next database fetch is triggered to refill the buffer (Reactor |
|
|
|
How many transactions are processed simultaneously in the recovery pipeline (Reactor |
|
|
|
How many transactions are pre-fetched and buffered before processing begins (Reactor |