[
https://issues.apache.org/jira/browse/OPENJPA-2969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18111522#comment-18111522
]
Romain Manni-Bucau commented on OPENJPA-2969:
---------------------------------------------
[~solomax] conditionally by the DB supported precision I think it makes sense -
side note: anything "now()"related should likely use a Clock instance and we
can set it in the EMF/broker and enable to override it with a
setter/configuration, default can be systemUTC one.
> Instant.now() precision loss on DB round-trip
> ---------------------------------------------
>
> Key: OPENJPA-2969
> URL: https://issues.apache.org/jira/browse/OPENJPA-2969
> Project: OpenJPA
> Issue Type: Sub-task
> Components: jpa
> Affects Versions: 4.2.0
> Reporter: Maxim Solodovnik
> Assignee: Maxim Solodovnik
> Priority: Major
> Fix For: 4.2.0
>
>
> Discussion thread:
> https://github.com/apache/openjpa/pull/144#discussion_r3683003132
> **(medium)** `Instant.now()` carries micro/nano precision on modern JVMs; if
> the version column's precision is lower (MySQL TIMESTAMP defaults, Oracle
> DATE) the value read back differs from the in-memory version, producing
> spurious optimistic-lock failures on the next flush - the same reason
> TimestampVersionStrategy deliberately uses millisecond granularity. Should
> this truncate to a precision known to survive the DB round-trip?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
