Spartacus B2C OOB场景下托运流程事务回滚问题咨询

Let's break down this problem step by step—this UnexpectedRollbackException is a classic Spring transaction issue, and when paired with Hybris/Spartacus order processes, it usually ties back to how sub-process transactions interact with the main order transaction.

Core Problem Analysis #

You mentioned that the main order process (order-process-00002001-1603978375652) completed the SourceOrderAction (successfully procuring the NV10 product from Kobe Sannomiya Terminal Hotel), then launched the consignment sub-process (cons00002001_0_ordermanagement). The sub-process creates the consignment but immediately triggers a rollback, with the AbstractPlatformTransactionManager marking the entire global transaction as rollback-only.

This exception happens when:

1. A nested/sub transaction marks the transaction as rollback-only (usually due to an unhandled runtime exception or explicit rollback call)
2. The outer transaction still attempts to commit, which Spring blocks because the transaction is already marked for rollback.

Key Troubleshooting Steps #

1. Find the Root Cause Exception

First, dig past the UnexpectedRollbackException—it's almost always a wrapper for the actual exception that triggered the rollback. Check your Hybris server logs (look in hybris/log/tomcat/localhost.log or hybris/log/console.log) for the full stack trace. You're looking for a lower-level exception like:

• A database constraint violation (e.g., missing required field on consignment or consignmententry table)
• A service-layer exception (e.g., failed stock check, invalid shipping method)
• A null pointer exception in the consignment sub-process code

2. Inspect the Consignment Sub-Process Implementation

Look at the Java code behind the cons00002001_0_ordermanagement sub-process actions:

• Check if any service method called during consignment creation throws a RuntimeException (Spring automatically marks transactions for rollback on unchecked exceptions)
• Look for code that swallows exceptions (e.g., try-catch blocks that catch exceptions but don't rethrow them or handle the rollback explicitly)—this is a common culprit because it hides the error but still marks the transaction as rollback-only.
• Verify that all required fields for the consignment (e.g., shipping address, carrier code, warehouse) are being correctly populated before persistence.

3. Review Transaction Propagation in Process Definitions

Check your order process XML files (usually in yourstorefront/acceleratorfacades/resources/processes/ or commercefacades/resources/processes/) for:

• The transactional attribute on the <subprocess> tag that launches cons00002001_0_ordermanagement
• The transaction propagation setting (via propagation attribute). If it's set to REQUIRED (the default), the sub-process shares the same transaction as the main order process—so any rollback in the sub-process will kill the entire transaction. If your business logic allows it (e.g., keep the procurement even if consignment fails), you could set this to REQUIRES_NEW to isolate the sub-process transaction.

4. Enable Detailed Transaction Logging

Add these lines to your local.properties to get granular transaction logs:

log4j.logger.org.springframework.transaction=TRACE
log4j.logger.de.hybris.platform.tx=TRACE

Reproduce the issue, then look for log lines like:

• Marking transaction as rollback-only—this will tell you exactly which step triggered the rollback.
• Transaction creation/commit/rollback timestamps to map the sequence of events between the main process and sub-process.

5. Validate Database Constraints

Check the database schema for the consignment-related tables:

• Ensure that all non-nullable columns (e.g., CODE, ORDERPK, WAREHOUSEPK) are being populated correctly by the sub-process.
• Verify that foreign key relationships (e.g., to the order, warehouse) are valid—if the sub-process tries to link to a non-existent warehouse, the database will throw an exception that triggers the rollback.

Potential Fixes #

• Fix the root exception: If you find a constraint violation or service error, address that directly (e.g., populate missing fields, fix stock logic).
• Adjust transaction propagation: If business rules allow, set the sub-process transaction propagation to REQUIRES_NEW to prevent sub-process failures from rolling back the entire order procurement.
• Fix exception handling: Remove any silent exception swallowing in the sub-process code—let exceptions propagate so the process engine can handle them properly (e.g., trigger an error event instead of silently marking the transaction for rollback).

内容的提问来源于stack exchange，提问作者anoop kumar