All entries for Wednesday 24 August 2005

August 24, 2005

hibernate and their stupid error messages ;)

So I have a Page, which has a Lock. Because lock only exists within a Page it was modelled as a component. Fine.

Unfortunately if a page is locked, sometimes all child pages need to be locked, and this potentially means 1000s of pages needing to be locked. As the lock is done via the object model, we very quickly run into memory problems. So I decided to model Lock as a seperate object (ta Chris May for the idea) with a link to the Page. 1000s of Lock objects is fine.

Anyways, I did this via one-to-one, with cascade="all-delete-orphan" on the Page, and creating a lock works. Deleting a page also deletes the lock, but how the flip do you remove just the lock! Calling page.setLock(null) fails. Calling lock.setPage(null) fails!

So in the end I gave up and modelled it as Page has many Locks. Page internally has a Set of locks, and setLock(Lock) just removes all existing locks and adds the new lock, so the set will only ever contain a single Lock.

Unfortunately I started getting this helpful error:

org.hibernate.StaleStateException: Batch update returned unexpected row count from update: 0 actual row count: 0 expected: 1
at org.hibernate.jdbc.BatchingBatcher.checkRowCount(
at org.hibernate.jdbc.BatchingBatcher.checkRowCounts(
at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(
at org.hibernate.jdbc.AbstractBatcher.executeBatch(
at org.hibernate.engine.ActionQueue.executeActions(
at org.hibernate.engine.ActionQueue.executeActions(
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(
at org.hibernate.impl.SessionImpl.flush(
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at junit.framework.TestCase.runTest(
at junit.framework.TestCase.runBare(
at junit.framework.TestResult$1.protect(
at junit.framework.TestResult.runProtected(
at junit.framework.TestSuite.runTest(
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(

It turns out that setLock(null) added a null object to the Set of locks which hibernate could not then persist. This (I presume) happens because hibernate first does an insert to create the page lock record, then does a corresponding update to create the reference to the parent. Kinda fishy really. I would either expect hibernate to blow up saying cannot persist null, or to simply skip that entry. I wouldn't expect it to do the insert but not the update!

Not adding nulls to the set works fine. Not that I should be using a stinking one-2-many to model a one-2-one in the first place!!!!

Hibernate, love it or hate it, or in this situation, both!

August 2005

Mo Tu We Th Fr Sa Su
Jul |  Today  | Sep
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31            

Search this blog



Most recent comments

  • Interesting… While I'm not completely convinced in such microbenchmarks, I'm pretty sure that 1ms … by Alexander Snaps on this entry
  • Hello. I bought the book yesterday. I was trying to find the source code for chapter 11 and chapter … by Suleman on this entry
  • by live mashup demo on this entry
  • Thanks mate ….. This blog was really helpful. by Maaz Hurzuk on this entry
  • Ty. Not directly helpful for my problem, but pointed me in the right direction. You will also get th… by Mike E. on this entry

Blog archive

Not signed in
Sign in

Powered by BlogBuilder