@Bean
public IgnoredNotificationStateRepository ignoreOrderPersistenceNotification() {
// returning null leaves Order persistence notifications enabled
return null;
}
- v1.0.0-latest-prod
|
Warning
|
Breaking Change: The semantics of |
Previously, message idempotency checks (which require a permanent lock to prevent duplicate execution) and short-lived resource concurrency guards (which only require a temporary lock) were conflated into a single locking API (POST /order-resource-locks).
This endpoint used temporal locks (which expired based on a default TTL) and expired locks could allow duplicate messages to be re-processed after the TTL elapsed, breaking event deduplication.
In this release, we have decoupled the two behaviors into separate APIs:
POST /order-resource-locks (Semantics Updated):
Its behavior has been restricted: it now strictly obtains a permanent lock (by calling repository.lockResource()). It is reserved exclusively for message idempotency checks to permanently block duplicate event processing.
Breaking Semantic Change: It no longer returns temporal locks that expire after a TTL. Do not use this endpoint for short-lived resource protection.
POST /order-resource-locks/temporal (New Endpoint):
Introduced to obtain short-lived temporal resource locks (calling repository.lockResourceTemporarily()).
Custom Configurable TTL: Callers can provide an optional lockTtl query parameter (of type Duration, e.g., PT10S in ISO-8601 duration format) to override the default TTL.
Default TTL Fallback: If not specified, the API falls back to the default duration configured via the broadleaf.order.web.order-lock-ttl property (which defaults to 10 seconds).
Order Services no longer publishes persistence notification messages for Order and OrderFulfillment.
These messages carried change details for every order write and were consumed by nothing in the platform, so producing them cost throughput on the most used write path in the service.
Any integration that subscribes to persistence events for orders or order fulfillments stops receiving them after upgrading.
If your implementation relies on these persistence events, see the snippet below to restore them.
Broadleaf registers the suppression as named, conditional beans, so an implementation that still needs these messages can switch them back on by defining a bean of the same name:
@Bean
public IgnoredNotificationStateRepository ignoreOrderPersistenceNotification() {
// returning null leaves Order persistence notifications enabled
return null;
}