swaldman / c3p0

a mature, highly concurrent JDBC Connection pooling library, with support for caching and reuse of PreparedStatements.

Home Page:http://www.mchange.com/projects/c3p0

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

NewProxyPreparedStatement nondeterminism

bmwiedemann opened this issue · comments

While working on reproducible builds for openSUSE, I found that
our c3p0 package varied between builds.

Among others, there was

c3p0-0.9.5.5.src/build/codegen/com/mchange/v2/c3p0/impl/NewProxyPreparedStatement.java
@@ -1,6 +1,6 @@
 /*
  * This class generated by com.mchange.v2.c3p0.codegen.JdbcProxyGenerator$NewProxyAnyStatementGenerator
- * Tue Apr 19 06:25:50 GMT 2022
+ * Tue Apr 19 06:27:10 GMT 2022
  * DO NOT HAND EDIT!!!!
  */     
 package com.mchange.v2.c3p0.impl;
@@ -58,13 +58,13 @@
         NewProxyPreparedStatement(PreparedStatement inner)
        { __setInner( inner ); }
        
-       public final void setArray(int a, Array b) throws SQLException
+       public final void setTime(int a, Time b, Calendar c) throws SQLException
        {  

It obviously suffers from ordering issues and a timestamp that does not consider SOURCE_DATE_EPOCH.

Can you help make it deterministic?

Hi,

Besides the timestamp in source comments, c3p0 builds also include a build timestamp (emitted in the logs on pool init at INFO). Will that also give you trouble? All the timestamps have issues, they are just intended as informal notations of about when a version was built, they're not exact since e.g. generated source files won't rebuild if the final build happens some time after their generation. Still, there is some (for humans) informational value there. They are very close to accurate for clean builds.

Would it be sufficient for you if the build supported a SOURCE_DATE_EPOCH environment variable that overrides the system clock so that your rebuilds could be deterministic?