jakarta.persistence.OptimisticLockException

[lkindere]

Describe the bug

During the execution of our maintenance operations (RewriteManifestsSparkAction) we noticed this exception:

CommitStateUnknownException: Service failed: 500: jakarta.persistence.OptimisticLockException: Exception [EclipseLink-5006] (Eclipse Persistence Services - 4.0.5.v202412231137-a96b873527f305f932543045c8679bb1de8d3a43): org.eclipse.persistence.exceptions.OptimisticLockException
Exception Description: The object [org.apache.polaris.jpa.models.ModelEntity@429b223f] cannot be updated because it has changed or been deleted since it was last read. 
Class> org.apache.polaris.jpa.models.ModelEntity Primary Key> [[51, 448]: 2990]
Cannot determine whether the commit was successful or not, the underlying data files may or may not be needed. Manual intervention via the Remove Orphan Files Action can remove these files when a connection to the Catalog can be re-established if the commit was actually unsuccessful.
Please check to see whether or not your commit was successful before retrying this commit. Retrying an already successful operation will result in duplicate records or unintentional modifications.
At this time no files will be deleted including possibly unused manifest lists.
Caused by: ServiceFailureException: Service failed: 500: jakarta.persistence.OptimisticLockException: Exception [EclipseLink-5006] (Eclipse Persistence Services - 4.0.5.v202412231137-a96b873527f305f932543045c8679bb1de8d3a43): org.eclipse.persistence.exceptions.OptimisticLockException
Exception Description: The object [org.apache.polaris.jpa.models.ModelEntity@429b223f] cannot be updated because it has changed or been deleted since it was last read. 
Class> org.apache.polaris.jpa.models.ModelEntity Primary Key> [[51, 448]: 2990]
Exception Description: The object [org.apache.polaris.jpa.models.ModelEntity@429b223f] cannot be updated because it has changed or been deleted since it was last read. 
Class> org.apache.polaris.jpa.models.ModelEntity Primary Key> [[51, 448]: 2990]
Cannot determine whether the commit was successful or not, the underlying data files may or may not be needed. Manual intervention via the Remove Orphan Files Action can remove these files when a connection to the Catalog can be re-established if the commit was actually unsuccessful.
Please check to see whether or not your commit was successful before retrying this commit. Retrying an already successful operation will result in duplicate records or unintentional modifications.
At this time no files will be deleted including possibly unused manifest lists.

Is this something that could be retry-able from Polaris catalog implementation itself or should each application using the catalog implement retries to handle this?

To Reproduce

Likely concurrent updates during maintenance operations

Actual Behavior

Polaris returns 500

Expected Behavior

Some sort of retry mechanism and successful execution

Additional context

No response

System information

Polaris 1.0 snapshot