[Hibernate] Batch update returned unexpected row count

[David Brossard]

Hi everyone,

I've written 2 small classes to manipulate my db through Hibernate. My first class, called table, is generic and deals with session / transaction management. The second class extends the first one and contains the actual object I want to add / update / delete.

When I test my class, I can easily add or delete provided I do them in 2 different tests, but I run the tests in a row and try to delete what I've just created, it fails with the following error:

org.hibernate.StaleStateException: Batch update returned unexpected row count from update: 0 actual row count: 0 expected: 1

I'm not sure I'm actually talking to Hibernate the right way, specially when it comes to handling the sessions and the underlying transactions. I'd greatly appreciate some insight on this please. My Table code is as follows:

import java.util.List;
import org.hibernate.Session;
 
public class Table {

protected static Session session = null;
protected static String tableName = "Table";

public Table(){
if (session == null) session = HibernateUtil.openSession();
        session.beginTransaction();
}

/**
 *  This method saves (inserts) the current object into the database
 *  
 * @throws Exception
 */
public void save() throws Exception{
        session.save(this);
session.getTransaction().commit();
}

public void update() throws Exception{
session.update(this);
session.getTransaction().commit();
}

public void delete() throws Exception{
session.delete(this);
session.getTransaction().commit();
session.clear();
}

/*public static void delete(Object o) throws Exception{
if (session == null) session = HibernateUtil.openSession();
        session.beginTransaction();
session.delete(o);
session.getTransaction().commit();
}*/

public static List list(String mappingName)
{
    session = HibernateUtil.openSession();
    session.beginTransaction();
    List result = session.createQuery("from "+mappingName).list();
    session.getTransaction().commit();
    return result;
}
 
}

My other class extends the one above and has the right setters / getters.

Thanks cowboys!

[pascal betz]

Unless i missed something it looks like you never close the session ?
It is important that the sesion gets closed after your done with your operations.

usually the following pattern is used:

Session s = ...
Transaction tx = null;
try {
  tx = s.beginTransaction();
  Object obj = s.doSomething();
  tx.commit();
  return obj;
} catch(Exception e) {
  if (tx != null) {
    tx.rollBack();
  }
} finally {
  if (s != null) {
    s.close(); // 
  }
}
 

Of course it is tedious to wriote this code all the time so there are different pattterns and utilities to make life easier (e.g. Springframework).

Also i would suggest to extract the code that works with hibernate from your business classes because like this you tie your business classes to hibernate.


The error message means that hibernate expected to update a row but did not. Sounds like it did not find an entry in the DB which was expected to be there. E.g. on an update Hibernate executes SQL like this:

update SOME_TABLE set .... WHERE PK = 12


and then checks how many rows were affected. On an update of an entity which was previously persisted it expects to get an update count of 1.

Pascal

[David Brossard]

Are you saying that every time I do an insert / delete / update, I need to close the session?

I found a work-around: clearing the session (which is equivalent to closing and opening again).

My main concern is that several users could be accessing the same db so I do really want to make sure they all get a coherent picture of the db in which I don't want any caching at hibernate level. Would disabling persistance make sure that everytime I do sthg it updates the db?

[David Brossard]

I noticed there's an autocommit in the hibernate config I probably want to set to true. That would enforce Hibernate to send / get data to / from the db as soon as the request is made, right?

[pascal betz]

do not send autocommit to true (from the docu:

Enables autocommit for JDBC pooled connections (not recommended).

(

The Session is short living while the SessionFactory is long living.
Your right: opening a session for every operation (insert/delete/update) is not the way to go. Instead you open a Session for a "business operation" (e.g. loading a user, changing his password and storing it again).

What do you mean by "several users" are accessing the same DB ? Are there applications accessing the DB directly or are several users accessing the DB trough Hibernate ?
In the first case you probably do not want the 2nd level cache, in the second you just go trough hibernate and don't worry. Hibernate takes care that people do not see stale data (thats why you are starting/ending a TX)

I found a work-around: clearing the session (which is equivalent to closing and opening again).

You should really close the Session after your done. As far as i know the Session is associated with a JDBC Connection which needs to be released after use (it might time out otherwise), also you do not want different Threads accessing the same Session as the Session is not Thread safe.


pascal

[Mat Brown]

For anyone who happens on this thread in a Google search or what have you - I searched on this for a while and came across one possible answer (relevant only if you are using display:table in your CSS):
http://www.webmasterworld.com/forum83/6673.htm

[David Newton]

Not to wake the zombie, but huh?

[Nat Kidder]

Got the same error on commit; fixed it by changing new Configuration().configure().buildSessionFactory().openSession().update to ~~~.save(). Of course, that isn't much help if you're trying to update and not insert.

[Nat Kidder]

I was able to fix it using Hibernate session.update() -- you need to have the table/view's primary key equal your corresponding bean property (eg. id). Once I got that, the error went away. (I did it using a Struts ActionForm, by the way.)

[Marty Diamond]

I had this error because I was trying to insert an item with an autogenerate id but where there was a nonzero value in the id. Hibernate, of course, tried to find the item to update and it wasn't there. It didn't insert it because the id was nonzero.