Deprecating EclipseLink makes sense to me. It served well in the early days of Apache Polaris, but at this stage the new JDBC impl. outperforms it in terms of ease of use and concurrency, I think.
I'd suggest marking the upcoming 1.0 release at the last release with EclipseLink, unless we know of users that still rely on EclipseLink and do not have an upgrade path to JDBC. Cheers, Dmitri. On Fri, May 2, 2025 at 6:02 PM Prashant Singh <prashant.si...@snowflake.com.invalid> wrote: > Hi all, > > I’d like to get your thoughts on deprecating EclipseLink and making JDBC > the default for our persistence layer. > > Our current EclipseLink setup mandates execution within a transaction, > which has introduced several issues — notably, an improper implementation > of CAS (compare-and-swap) semantics. To address these shortcomings, Apache > Polaris underwent a major refactor to decouple persistence interfaces from > strict transaction dependencies and to ensure actual CAS enforcement. > > As part of this effort, we introduced a new JDBC backend with a simpler and > more performant schema, directly addressing the limitations of the existing > EclipseLink schema. > > We’ve observed significant improvements compared to the EclipseLink > implementation. Notably, issues such as Polaris failing under minimal > concurrency (e.g., with just 5 users) have been resolved: > https://github.com/apache/polaris/issues/1123#issuecomment-2756133924 > > Given these improvements, I propose we: > > - > > Deprecate EclipseLink > - > > Make relational JDBC the default persistence implementation > > PR to support this change: > [1] https://github.com/apache/polaris/pull/1515 > > Would love to hear your feedback on this. > > Best regards, > Prashant >
