I have a project using EclipseLink-2.6.0 and UCanAccess-3.0.4 (as DB driver) to modify an MS Access database. (NB legacy requirement - not my choice).
There is a table with a column of single precision (Again, legacy requirement - not my choice).
If the field is updated then any updates after that point 'appear' to be committed, but after closing and reopening the database the last update to the field is always the initial update and all other updates have been lost.
I have put together a project that has tests this scenario using both JPA and using JDBC directly. The JDBC connection correctly flushes the changes to the database, while the JPA test does not.
The URL for the test project is: https://github.com/william-ferguson-au/eclipselink-flush-test
NB the UCanAccess connection is configured with SingleConnection=true because I need to ensure that once the EntityManagerFactory is closed, the lock on the MS Access DB is released. I think this is now the crux of the issue.
The failing test output looks something like:
[EL Info]: server: 2016-05-01 17:59:35.858--ServerSession(1690826692)--Detected server platform: org.eclipse.persistence.platform.server.NoServerPlatform.
lastValue=0.0 entry#value=0.0 newValue=1.4
lastValue=1.4 entry#value=1.4 newValue=2.8
lastValue=2.8 entry#value=2.8 newValue=4.2
lastValue=4.2 entry#value=4.2 newValue=5.6
lastValue=5.6 entry#value=5.6 newValue=7.0
lastValue=7.0 entry#value=7.0 newValue=8.4
lastValue=8.4 entry#value=8.4 newValue=9.8
lastValue=9.8 entry#value=9.8 newValue=11.2
lastValue=11.2 entry#value=11.2 newValue=12.6
lastValue=12.6 entry#value=12.6 newValue=14.0
lastValue=14.0 entry#value=14.0 newValue=15.4
lastValue=15.4 entry#value=15.4 newValue=16.8
lastValue=16.8 entry#value=16.8 newValue=18.2
Database - closed
Database - reopened
[EL Warning]: 2016-05-01 17:59:39.906--session_manager_no_partition
lastValue=18.2
[EL Info]: server: 2016-05-01 17:59:39.922--ServerSession(1276502808)--Detected server platform: org.eclipse.persistence.platform.server.NoServerPlatform.
lastValue=18.2 entry#value=1.4 newValue=28.2
[EL Warning]: 2016-05-01 17:59:40.568--session_manager_no_partition
java.lang.AssertionError: Expected=18.2 found=1.4
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at au.com.xandar.eclipselink.flush.DoubleFlushTest.verifyEntityValue(DoubleFlushTest.java:133)
at au.com.xandar.eclipselink.flush.DoubleFlushTest.testExplicitUpdatesJPA(DoubleFlushTest.java:120)
If I set SingleConnection=false when configuring the EntityManagerFactory then the updates are flushed to the database and are visible when the database is reopened. But then I have no way of releasing the file lock on the MS Access DB until, the VM is destroyed.
So I thought it was a bug in EclipseLink (https://bugs.eclipse.org/bugs/show_bug.cgi?id=492773). But now I am thinking it is more likely a bug in the way that UCanAccess handles SingleConnection=true in a JPA environment. Or perhaps I am missing some config that is required in order to make EclipseLink JPA flush in the same manner as JDBC.
Dies this should like expected behaviour using UCanAccess and SingleConnection=true?
FOLLOW UP #1
@GordThompson pointed out that the original DB field was single rather than double. And that changing the DB field to double (to match the original Entity field) made everything work OK. But I can't change the DB. So I changed the Entity field to Float (ie single) to match the DB field and the problem remains and is even more pervasive.
Then I realised that the behaviour changes depending upon the value of the UCanAccess SingleConnection property in a JPA environment.
FOLLOW UP #2
It is replicable using UCanAccess only when using a PreparedStatement and SingleConnection=true. See updated test cases.
FOLLOW UP #3 It appears that the problem only becomes apparent when making updates to a Float/Double field, closing the DB, opening the DB, checking the field, closing the DB, repeat same for a different DB at which point none of the values for the 2nd DB get persisted. Still occurring with UCanAccess-3.0.5
Discusion moved to https://sourceforge.net/p/ucanaccess/discussion/general/thread/a6a192d0
This is a critical bug due to a misalignment, under specific conditions, between the mirror hsqldb database and the data persisted in the mdb. It indirectly depends on the way the FLOAT data are managed in hsqldb. I've already found the solution, so the fix will be in the 3.0.5. I'm going to release it ASAP, hopefully this week end, at later the next week. Thank you guys!