Hibernate version: 3.0


Getting the following exception when calling commit:

java.util.NoSuchElementException: :
at org.apache.commons.collections.SequencedHashMap$OrderedIterator.next(SequencedHashMap.java:798)
at org.hibernate.util.IdentityMap.entryArray(IdentityMap.java:195)
at org.hibernate.util.IdentityMap.concurrentEntries(IdentityMap.java:59)
at org.hibernate.event.def.AbstractFlushingEventListener.prepareEntityFlushes(AbstractFlushingEventListener.java:104)
at org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:59)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:26)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:730)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:324)
at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:86)

Any ideas?

Name and version of the database you are using: oracle 9

It also looks like you truncated your stack trace. If there's more to it, post it all please.

First thing i should've mentioned is that this happens rarely, we have an app that's executing this code 3M times/day, and we get this exception about 20-30 times/day (ie, 1 failure out of every 100k). It looks like some sort of race-condition bug either in commons collection or hibernate. We do have multiple threads executing this code, but each thread gets its own session.

Just wondering if anybody has seen this before. I don't know why other info would be relevant, in particular the rest of the stack trace since that's just our code.

Neither the Hibernate Session nor commons-collections can possibly have a race condition bug, because they are both single threaded.

Figure out why your app has two threads both accessing the same Hibernate Session instance.

Hmm, the code looks pretty straightforward:

{
Session session = SessionFactory.openSession();
try { // use the session }
finally { session.close(); }
}

The session object lives only for the duration of the request, doesn't even get exposed outside the method. Can't see how some other thread would be using it.

Hi,

Did you ever fix this problem? We have the same issue when processing a large bulk by multiple threads and it only occurs between 4-8 times with 4 mln transactions.

Cheers,
Maarten

http://opensource2.atlassian.com/projec ... e/HHH-1293
It looks like similar problem, try "-server" option.

We no longer see this problem, but we have since upgraded the jvm as well as the OS (RH linux). We are now using sun's jdk1.5_06 version.

Note that we always had been using the -server option, so that's not the answer.

Understand that if the problem is some subtle race-condition, or java memory-model issue, any kind of change could hide it; so it could still be there. On the other hand, it may have been a jdk bug that was fixed as well.