On 4/6/18 6:07 AM, palo.liska wrote:
Rick Hillegas-3 wrote
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.
application is under stress test.

Rick Hillegas-3 wrote
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.
..so could this means that there is issue in hibernate? (meanwhile I will
try to google it :))
Technically, Hibernate should not be calling getGeneratedKeys() because Derby's DatabaseMetaData says that the method is not supported. But whoever wrote the porting layer on top of Derby must have cribbed the code from another database which does support that method. Derby should raise an exception when that method is called, or Derby should fix the implementation of getGeneratedKeys(). So you are caught between bugs in two layers: Hibernate and Derby.

Nevertheless, I am currious about this tooMuchContetionException. It is
called in SequenceUpdater.getCurrentValueAndAdvance(..). However, this
method is synchonized. So concurrent generation of Ids should not be problem
(correct me if I am wrong). In method body there is comment

...Lock contention is possible if someone has selected from SYSSEQUENCES
contrary to our advice. In that case, we raise a TOO MUCH CONTENTION
I have one custom sequence in SYSSEQUENCES, and I am getting new value with
query "VALUES (NEXT VALUE FOR my_seq)". Could this be the problem, or there
could be some other? Besides this I am not using SYSSEQUENCES explicitly.
Contention occurs when a thread needs to allocate a new block of sequence numbers. A lock on the relevant row in SYSSEQUENCES is acquired in this situation. Contention can occur if someone else holds the lock on that row. Other potential lock holders are sessions which directly query SYSSEQUENCES, callers of getGeneratedKeys(), and the engine shutdown thread.

Sent from: 

Reply via email to