Hibernate Delete Error: Batch Update Returned Unexpected Row Count

前端 未结 8 1733
余生分开走
余生分开走 2020-12-04 16:44

I wrote this method below that is suppose to delete a member record from the database. But when I use it in my servlet it returns an error.

MemberDao Class

相关标签:
8条回答
  • 2020-12-04 17:25

    i recently experienced this and what happened was that i used the update method and it was throwing an exception because there was no existing record. I changed the method to saveOrUpdate. It worked.

    0 讨论(0)
  • 2020-12-04 17:27

    this is the solution for my case, maybe it will help you!

    Actually it was a conversion problem between a database field type (timestamp on postgreSQL) and his equivalent property type (Calendar) on hibernate xml file. When Hibernate did this update request, it didn't retrieve the row because the request interrogate with a bad convert Calendar value. So I simply replaced property type "Calendar" in "Date" in Hibernate xml file and the problem was fixed.

    0 讨论(0)
  • 2020-12-04 17:36

    I was facing same issue. The code was working in the testing environment. But it was not working in staging environment.

    org.hibernate.jdbc.BatchedTooManyRowsAffectedException: Batch update returned unexpected row count from update [0]; actual row count: 3; expected: 1
    

    The problem was the table had single entry for each primary key in testing DB table. But in staging DB there was multiple entry for same primary key. ( Problem is in staging DB the table didn't had any primary key constraints also there was multiple entry.)

    So every time on update operation it gets failed. It tries to update single record and expect to get update count as 1. But since there was 3 records in the table for the same primary key, The result update count finds 3. Since expected update count and actual result update count didn't match, It throws exception and rolls back.

    After the I removed all the records which have duplicate primary key and added primary key constraints. It is working fine.

    0 讨论(0)
  • 2020-12-04 17:37

    The exception org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1 use to be thrown when Hibernate notice that the entity he wants to flush to the database isn't exactly as it was at the beginning of the transaction.

    I described more in details two different use cases that happen to me here.

    0 讨论(0)
  • 2020-12-04 17:39

    The error can be caused by several things. I'm not taking the credit for it, found it here.

    1. Flushing the data before committing the object may lead to clear all object pending for persist.
    2. If object has primary key which is auto generated and you are forcing an assigned key
    3. if you are cleaning the object before committing the object to database.
    4. Zero or Incorrect ID: If you set the ID to zero or something else, Hibernate will try to update instead of insert.
    5. Object is Stale: Hibernate caches objects from the session. If the object was modified, and Hibernate doesn’t know about it, it will throw this exception — note the StaleStateException

    Also look at this answer by beny23 which gives a few further hints to find the problem.

    • In your hibernate configuration, set hibernate.show_sql to true. This should show you the SQL that is executed and causes the problem.
    • Set the log levels for Spring and Hibernate to DEBUG, again this will give you a better idea as to which line causes the problem.
    • Create a unit test which replicates the problem without configuring a transaction manager in Spring. This should give you a better idea of the offending line of code.
    0 讨论(0)
  • 2020-12-04 17:41

    In my case this exception was caused by wrong entity mapping. There were no cascade for relation, and referenced child entity wasn't saved before trying to reference it from parent. Changing it to

        @OneToMany(cascade = CascadeType.ALL)
    

    fixed the issue.

    Surely best way to find cause of this exception is setting show_sql and DEBUG level for logs - it will stop just at the sql that caused the problem.

    0 讨论(0)
提交回复
热议问题