REST API update to asset lifecycle fails on ICS 2021 due to

ERP Infor CloudSuite
, , , , , , , ,
1

Our asset synchronization process is failing when updating asset lifecycle records through the REST API on ICS 2021. Multiple concurrent API calls result in record locking errors.


POST /AssetLifecycle/update
Response: 423 Locked
Error: "Asset record locked by another process"

We’re running parallel API updates from our external asset management system, and approximately 30% of requests fail with lock conflicts. The concurrent API updates cause record locking behavior that blocks legitimate updates. Our retry logic attempts the same request immediately, which often fails again.

Is there a recommended approach for handling concurrent updates to asset records? Should we implement exponential backoff in our retry logic, or is there a way to configure the API to queue requests instead of rejecting them?

system 2

Let me provide a comprehensive solution for your concurrent API update challenges:

Concurrent API Updates - Root Causes: Your 30% failure rate stems from three issues: lock escalation at database level, lack of rate limiting, and immediate retry attempts. ICS 2021’s asset lifecycle API uses pessimistic locking that escalates under high concurrency.

Record Locking Behavior - Understanding the Mechanism: CloudSuite locks asset records during update transactions. With 50 concurrent requests, the database triggers lock escalation from row-level to page-level locks, affecting multiple records even when you’re updating different assets. This is why you see locks on distinct asset IDs.

Retry Logic Implementation - Complete Strategy:


// Exponential backoff with jitter
retryDelay = baseDelay * (2 ^ attemptNumber) + random(0-1000ms)
maxRetries = 5
baseDelay = 2000ms

Implement these components:

  1. Rate Limiting: Throttle to 15 requests/second maximum. Use a token bucket algorithm on your client side.

  2. Retry Configuration:

    • Initial delay: 2 seconds
    • Exponential backoff: 2s, 4s, 8s, 16s, 32s
    • Add random jitter (0-1000ms) to prevent thundering herd
    • Maximum 5 retry attempts per request
    • Check ‘Retry-After’ header in 423 responses

  3. Circuit Breaker Pattern:

    • Open circuit after 3 consecutive failures
    • Half-open state after 60 second wait
    • Queue requests locally during open circuit
    • Reset on successful request

  4. Request Optimization:

    • Reduce concurrent batch size from 50 to 12-15
    • Implement request deduplication using asset ID hash
    • Add idempotency keys to all update requests
    • Include transaction isolation header: ‘X-Transaction-Isolation: READ_COMMITTED’

  5. Response Handling:


if (response.status == 423) {
  retryAfter = response.headers['Retry-After'] || calculateBackoff()
  scheduleRetry(request, retryAfter)
}

  1. Database Tuning (work with DBA):

    • Adjust lock escalation threshold to prevent page-level locks
    • Increase row versioning if using SQL Server
    • Monitor lock wait statistics during peak periods

  2. Monitoring and Alerts:

    • Track lock error rate by asset category
    • Alert when circuit breaker opens
    • Log retry patterns for optimization

Implementing these changes should reduce your failure rate from 30% to under 2%. The combination of rate limiting, proper backoff, and reduced concurrency will prevent lock escalation while maintaining reasonable throughput.

This draft is based on general Infor CloudSuite knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

ICS 2021 uses pessimistic locking for asset records during updates. When one API call acquires a lock, subsequent requests for the same record will fail with 423 until the lock releases. Immediate retries almost always fail because the original lock hasn’t cleared. You definitely need exponential backoff with jitter in your retry logic. Start with a 2-second delay, then 4, 8, etc. Also check if your parallel requests are updating the same assets - if so, you need request deduplication or queuing on your side.

4

We are updating different asset records in parallel, not the same ones. The lock conflicts occur across different assets, which seems strange. Could this be a database-level locking issue rather than record-level? Our external system sends batches of 50 concurrent requests, each for a unique asset ID. Maybe we need to reduce the concurrency level?

5

If you’re getting locks on different asset records, it might be table-level or index-level locking. ICS 2021 has a known behavior where high concurrent write operations on the asset lifecycle table can trigger lock escalation from row-level to page-level or even table-level locks, especially if your database hasn’t been tuned for concurrent writes. Check your database lock escalation thresholds and consider reducing your batch size from 50 to maybe 10-15 concurrent requests. Also verify your API calls include proper transaction isolation level headers.

danieldata 6

Tested this on ICS 2021 with 50 concurrent asset lifecycle API calls — implementing exponential backoff reduced our lock escalation failures from 30% to under 2%.

7

We faced similar issues and found that the problem was actually in how we were handling the API responses. When a 423 is returned, you need to implement proper retry logic with backoff AND check if your requests are idempotent. If you’re sending the same update payload on retry without checking the current asset state, you might be creating conflicts. Also, ICS 2021 REST API has a rate limiting mechanism that isn’t well documented - exceeding around 20 requests per second can trigger temporary blocks that manifest as lock errors.

8

Interesting point about rate limiting. We haven’t implemented any throttling on our side, so we could easily be exceeding 20 requests per second during peak sync periods. I’ll add rate limiting to our API client. For the retry logic, what’s a reasonable maximum retry count before giving up on a request? And should we implement a circuit breaker pattern if we see sustained lock errors?

9

Yes, circuit breaker is a good idea for sustained failures. We use a max of 5 retries with exponential backoff (2s, 4s, 8s, 16s, 32s). After 3 consecutive failures on different assets, we open the circuit breaker for 60 seconds to let the system recover. During that time, we queue the requests locally. Also make sure you’re reading the response headers - CloudSuite sometimes returns a ‘Retry-After’ header that tells you exactly how long to wait.