Skip to content

Avoid serving a zero cache after identity failure - #37323

Open
kalayciburak wants to merge 1 commit into
spring-projects:mainfrom
kalayciburak:fix/identity-incrementer-zero-cache
Open

kalayciburak wants to merge 1 commit into
spring-projects:mainfrom
kalayciburak:fix/identity-incrementer-zero-cache

Conversation

@kalayciburak

Copy link
Copy Markdown

AbstractIdentityColumnMaxValueIncrementer assigned valueCache and nextValueIndex before the insert/identity loop finished.

If executeUpdate failed, the zero-filled cache stayed published. The next nextLongValue() skipped the database and returned 0. A later failure in a cacheSize > 1 batch had the same shape: the incomplete cache was already visible.

The cache is now built locally and published only after every identity read succeeds. A failed allocation leaves the previous index unchanged, so the next call retries. The cleanup delete still runs after publish, so a delete failure does not drop ids that were actually allocated.

This is the identity-column path (HSQL, Sybase, Derby, SQL Server, MySQL identity). It does not change MySQLMaxValueIncrementer.

Before the fix, AbstractIdentityColumnMaxValueIncrementerTests expected 7 and got 0 after a failed insert. After the fix that test, the partial-batch case, and DataFieldMaxValueIncrementerTests pass.

AbstractIdentityColumnMaxValueIncrementer published valueCache and
nextValueIndex before the insert/identity loop finished. A failed
insert left a zero-filled cache in place, so the next call returned 0
instead of retrying the database. The same path served a partial
cache when a later insert in the batch failed.

Build the cache locally and publish it only after every identity read
succeeds. A failed allocation leaves the previous index unchanged, so
the next call retries. Cleanup delete still runs after publish, so a
delete failure does not discard ids that were actually allocated.

Signed-off-by: Burak KALAYCI <kalayciburak1996@gmail.com>
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Sep 22, 2026
@sbrannen sbrannen added the in: data Issues in data modules (jdbc, orm, oxm, tx) label Sep 22, 2026

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

in: data Issues in data modules (jdbc, orm, oxm, tx) status: waiting-for-triage An issue we've not yet triaged or decided on

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants