Thanks for attaching derby.log. A couple things jump out at me:
1) Something about the problem description is not clear. The first
tooMuchContention exception occurs within a half minute of booting the
database. It is very hard to understand how your application could chew
through 2 billion sequence numbers in that short time period. Perhaps
your identity column has already leaked its entire range due to setting
derby.language.sequence.preallocator to a high number and then crashing
without bringing the database down gracefully.
2) From the stack traces, it appears that you are using Hibernate. Under
the covers, Hibernate calls a JDBC method which Derby does not support
but which, unfortunately, Derby does not reject either
(Statement.getGeneratedKeys()). That method causes contention on the
sequence generators which back identity columns. See
https://issues.apache.org/jira/browse/DERBY-6934. It is likely that you
have stumbled over this problem. You may be able to workaround this
problem by manually generating your object IDs yourself (e.g., by using
a sequence generator) and somehow forcing those object ids down through
the Hibernate api. I don't use Hibernate myself, so I don't know what
this entails. Maybe you will get better advice from someone who has
dealt with this Hibernate/Derby issue.
Hope this helps,
-Rick
On 4/3/18 1:51 PM, palo.liska wrote:
Rick Hillegas-3 wrote
Can you share the derby.log for this problem?
Finally, I have derby.log, even with
derby.language.sequence.preallocator=2147483647.
