0

Currently upgrading our java/jsf/primefaces application, I'm facing folowing issue:

I changed the versioning date from Date datatype to LocalDateTime, since that i'm having a OptimistickLockException when saving an Entity for the second time, on my local machine. (Windows64 + Wildfly23 + OpenJDK 12 + oracle-ojdbc6 driver) I've already debugged showed the current values of the jpaVersion on screen everything is fine before the update.

On the dev server (Linux + Wildfly23 + OpenJDK 12 + oracle-ojdbc6 driver), it's working fine. Both share the same DB.

Someone have an idea what could be the cause ? Would appreciate you're help.

Best regards

Michael
  • 21
  • 3
  • 1
    Maybe post the stack trace? – Willis Blackburn Sep 27 '22 at 14:11
  • 12am isn't the same absolute millisecond value in all timezones so I wouldn't consider or try using LocalDateTime for versioning. Check the precision of the type in the database and check the values that inserted for a new record, and what exactly is showing up on the statement that causes the exception? JPA uses JDBC which only understands java.sql.Date values in the drivers so it'll likely come down to a conversion issue with the timezone. – Chris Sep 27 '22 at 21:29

1 Answers1

1

I figured it out: It has something to do with the precision of the clock where the application is running.

On the Windows I've a precision of nanoseconds(9) on the Linux deployments it has a precision of milliseconds(6), therefore in order use LocalDateTime on Multi-platforms (Windows/Linux) the time must be truncated/converted to milliseconds in order to avoid Locks. Or simply continue using Date for versioning, always has a precision of (6/Milliseconds).

Michael
  • 21
  • 3