NServiceBus 4.6.5 Oracle环境下SagaData间歇性未持久化问题咨询

Alright, let’s dig into this tricky intermittent problem you’re facing—where business data saves successfully but the corresponding SagaData fails to persist for a specific command type. Since most operations work fine, we can target our troubleshooting to a few key areas:

1. Validate Distributed Transaction Coordinator (DTC) Health #

Your suspicion about DTC is spot-on, especially with a multi-server deployment. Here’s how to verify:

• Check DTC configuration across all servers: On your main and two worker servers, open Component Services → Computers → My Computer → Distributed Transaction Coordinator → Local DTC. Right-click → Properties to confirm:
  • Network DTC Access is enabled
  • Allow Inbound/Outbound transactions are checked
  • No authentication restrictions (if your environment allows it, for testing)
• Test cross-server DTC connectivity: Run the command dtcutil ping <server-name> from each server to the others. This will confirm if DTC can communicate across nodes.
• Review DTC event logs: Open Windows Event Viewer → Applications and Services Logs → Microsoft → Windows → DistributedTransactionCoordinator. Look for warnings/errors around the time the issue occurs—common culprits include transaction timeouts, Oracle resource manager registration failures, or network interruptions.
• Align transaction timeout settings: Ensure NServiceBus’s transaction timeout (configured in UnicastBusConfig via TransactionTimeout) matches Oracle’s transaction timeout. Mismatched values can lead to partial commits where business data persists but SagaData rolls back.

2. Investigate NServiceBus 4.6.5 Saga-Specific Behavior & Configuration #

Since the issue is isolated to one command type, let’s look at your Saga implementation and NServiceBus’s handling:

• Verify transaction scope consistency: In NServiceBus 4.x, Saga Handle methods run in a transaction scope by default. Check if your Repository.AddObject call is using a nested transaction (e.g., TransactionScopeOption.RequiresNew). If it’s committing independently, a failure in the Saga’s transaction would leave business data intact but SagaData unsaved.
• Check SagaIndex and Oracle constraints: Your [SagaIndex("ExternalCombinedIdentifier")] creates an index on that column. Confirm in Oracle:
  • The index exists and has the correct uniqueness setting (if intended)
  • There are no constraint violation errors in Oracle’s alert log around the issue time—duplicate values would fail SagaData insertion but might not surface in your application logs.
• Enable verbose NServiceBus logging: Crank up the log level to Debug for NServiceBus components, especially NServiceBus.Persistence and NServiceBus.Transactions. Look for log entries like "Saga persister failed to save" or "Transaction rolled back" that might have been hidden at lower log levels.
• Explicitly mark SagaData changes: For complex properties like collections (Data.MyData), NServiceBus 4.x’s change tracking might miss updates. Try adding Data.MarkAsChanged() after modifying Data.MyData to force the persister to save the changes.

3. Rule Out Multi-Server Deployment Inconsistencies #

NServiceBus Saga persistence relies on a shared database, so node-to-node sync shouldn’t be an issue—but let’s confirm:

• Validate Oracle connection strings: Ensure all three servers use identical connection strings pointing to the same Oracle instance, schema, and SagaData tables. A misconfigured connection could cause one node to write to a different location.
• Audit Oracle sessions: Use Oracle’s v$session and v$sql views to track which server is processing the problematic command. Check if the corresponding INSERT statement for SagaData is being executed, and if so, why it’s failing (e.g., missing permissions, lock waits).
• Isolate nodes for testing: Temporarily take one worker server offline and test if the issue persists. If it stops, the problem might be specific to that node’s environment (e.g., corrupted NServiceBus installation, network issues).

4. Additional Testing & Debugging Steps #

• Reproduce with load testing: Use a tool like NServiceBus Load Test to send a high volume of the problematic IAddMyCommand messages. This can help turn intermittent failures into consistent ones, making debugging easier.
• Check Oracle performance metrics: Look for lock waits (v$lock), IO bottlenecks, or long-running transactions during issue times. A locked SagaData table could cause insertions to time out without throwing obvious errors.
• Test with a simplified Saga: Create a minimal version of your Saga that only handles IAddMyCommand and saves basic SagaData. If this works, the issue might be tied to the specific logic in your full Saga (e.g., the SagaUtilities.GetById call or collection modifications).

内容的提问来源于stack exchange，提问作者Miguel Domingos