Polaris persistence concurrency issues

[snazy]

Describe the bug

As pointed out on the mailing list, the current persistence implementation in Polaris, even if run with the required isolation level, yields errors like ERROR: could not serialize access due to read/write dependencies among transactions. The underlying test case, which runs concurrent modifications to different Iceberg tables (non-conflicting changes) and did not "overload" Polaris, should really never yield such errors to users.

This issue could be a consequence of #775, assuming that the behavior of one persistence backend can be ported 1:1 to another one.

To Reproduce

No response

Actual Behavior

No response

Expected Behavior

No response

Additional context

No response

System information

No response

[singhpk234]

This should be gone with new JDBC persistence, eclipse link has been deprecated. IMHO we should good !

@snazy please let us know if we can close this now.

[dimas-b]

The original dev list issue applies to EclipseLink. It is still included in Polaris, but it is deprecated (#1515). So, I do not think we should consider EclipseLink for the purpose of this issue anymore.

The new perf test suite appears to show a good degree of resilience in the new JDBC implementation under concurrent load (as reported on the dev ML).

From my POV this issue can be closed now.

While it would be worth continuing stress testing the new JDBC Persistence, we can probably handle any fallout from those tests as separate issues.

[singhpk234]

closing this as per ML list discussion