[
https://issues.apache.org/jira/browse/OPENJPA-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Albert Lee closed OPENJPA-2069.
-------------------------------
> Natvie sequence problems uncovered after OPENJPA-1376
> -----------------------------------------------------
>
> Key: OPENJPA-2069
> URL: https://issues.apache.org/jira/browse/OPENJPA-2069
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc, kernel
> Affects Versions: 2.1.2, 2.2.0
> Reporter: Albert Lee
> Assignee: Albert Lee
> Fix For: 2.2.0
>
>
> After OPENJPA-1376 commits, it uncovered a few issues, some old and some new.
> 1. Backward compatibility - Previous, openjpa relies on the native sequence
> to provide the next value based on the sequence's INCREMENT BY setting. Now
> that openjpa manages the next sequence value and allocation size, if the db
> sequence is manually created that does not match the application's increment
> and allocation size, committing a new entity may result a constraint
> violation exception when new sequence value is requested that crossed the
> allocation boundary. This behavior is indirectly documented in the migration
> consideration section in the user manual, but it would be better if this can
> be handled automatically or at least to provide a compatibility option to
> honor previous behavior.
> 2. Initial value always start with the same value (default to 1) - In
> NativeJDBCSeq, the _initial, _increment and _allocate are used for the CREATE
> SEQUENCE generation for SynchronizeMapping function. For existing db
> sequence, next returns whatever managed by the db sequence. After the commit,
> next will first return the_nextValue value in NativeJDBCSeq until _maxValue
> is reached, then it go to db to get the sequence's next value, which may be
> ways off from the current _maxValue.
> 3. _nextValue not handled proper when crossing _allocate boundary - When
> NativeJDBCSeq's _nextValue exceeds the _maxValue boundary, it queries db's
> sequence for the next incremental value and assign directly as the next
> return value. It works for incrementBy = 1 but for some value (e.g. 3), the
> difference of the before and after cross boundary values may NOT be the
> _increment value.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
