importar - leer excel desde java como si fuera una base de datos

Hibernate: la actualización por lotes ha devuelto el recuento de filas inesperado de la actualización: 0 Recuento de filas reales: 0 esperado: 1

Question

Obtengo el siguiente error de hibernación. Puedo identificar la función que causa el problema. Lamentablemente, hay varias llamadas DB en la función. No puedo encontrar la línea que causa el problema ya que hibernate vacia la sesión al final de la transacción. El error de hibernación mencionado a continuación parece un error general. Ni siquiera menciona qué Bean causa el problema. ¿Alguien familiarizado con este error de hibernación?

org.hibernate.StaleStateException: Batch update returned unexpected row count from update: 0 actual row count: 0 expected: 1
at org.hibernate.jdbc.BatchingBatcher.checkRowCount(BatchingBatcher.java:93)
at org.hibernate.jdbc.BatchingBatcher.checkRowCounts(BatchingBatcher.java:79)
at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:58)
at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:195)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:235)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:142)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:297)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:985)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:333)
at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106)
at org.springframework.orm.hibernate3.HibernateTransactionManager.doCommit(HibernateTransactionManager.java:584)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransacti
onManager.java:500)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManag
er.java:473)
at org.springframework.transaction.interceptor.TransactionAspectSupport.doCommitTransactionAfterReturning(Transaction
AspectSupport.java:267)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:106)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:170)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:176)

Answer 1

Acabo de encontrarme con este problema y descubrí que estaba borrando un registro y tratando de actualizarlo luego en una transacción de Hibernate.

Answer 2

Como dice , esto sucede cuando se produce una actualización en un objeto que tiene sus hijos eliminados. (Probablemente porque era necesario actualizar el Objeto paterno completo y, en ocasiones, preferimos eliminar a los niños y reinsertarlos en el padre (lo nuevo y lo viejo no importa) junto con cualquier otra actualización que el padre pueda tener sobre cualquiera de sus otros campos simples) Entonces ... para que esto funcione, elimine los elementos secundarios (dentro de una Transacción) llamando a childrenList.clear() (No childDAO.delete(childrenList.get(i).delete())) y elimínelos con algún elemento childDAO.delete(childrenList.get(i).delete())) y estableciendo @OneToMany(cascade = CascadeType.XXX ,orphanRemoval=true) en el lado del objeto padre. Luego actualice el padre (padreDAO.update (padre)). (Repita para cada objeto de padre) El resultado es que los niños eliminan su vínculo con su padre y luego son eliminados como huérfanos por el marco.

Answer 3

Después de leer todas las respuestas, no encontré a nadie para hablar sobre el atributo inverso de la hibernación.

En mi opinión, también deberías verificar en el mapeo de relaciones si la palabra clave inversa está apropiadamente configurada. La palabra clave inversa se crea para definir de qué lado está el propietario para mantener la relación. El procedimiento para actualizar e insertar varía según este atributo.

Supongamos que tenemos dos tablas:

principal_table , middle_table

con una relación de uno a muchos . Las clases de mapeo de hibernación son Principal y Medio respectivamente.

Entonces, la clase Principal tiene un conjunto de objetos medianos. El archivo de mapeo xml debería ser como sigue:

<hibernate-mapping>
<class name="path.to.class.Principal" table="principal_table" ...>
...
<set name="middleObjects" table="middle_table" inverse="true" fetch="select">
<key>
<column name="PRINCIPAL_ID" not-null="true" />
</key>
<one-to-many class="path.to.class.Middel" />
</set>
...

Como inverso se establece en "verdadero", significa que la clase "Medio" es el propietario de la relación, por lo que la clase principal NO ACTUALIZARÁ la relación.

Entonces, el procedimiento de actualización podría implementarse así:

session.beginTransaction();
Principal principal = new Principal();
principal.setSomething("1");
principal.setSomethingElse("2");
Middle middleObject = new Middle();
middleObject.setSomething("1");
middleObject.setPrincipal(principal);
principal.getMiddleObjects().add(middleObject);
session.saveOrUpdate(principal);
session.saveOrUpdate(middleObject); // NOTICE: you will need to save it manually
session.getTransaction().commit();

Esto funcionó para mí, pero puede sugerir algunas ediciones para mejorar la solución. De esa forma todos aprenderemos.

Answer 4

En mi caso, había un problema con la base de datos ya que uno de los procesadores almacenados consumía toda la CPU, lo que causaba tiempos de respuesta de base de datos altos. Una vez que esto se mató, el problema se resolvió.

Answer 5

En mi caso, llegué a esta excepción en dos casos similares:

• En un método anotado con @Transactional tuve una llamada a otro servicio (con largos tiempos de respuesta). El método actualiza algunas propiedades de la entidad (después del método, la entidad aún existe en la base de datos). Si el usuario solicita dos veces el método (ya que cree que no funciona la primera vez) al salir del método transaccional la segunda vez, Hibernate intenta actualizar una entidad que ya cambió su estado desde el comienzo de la transacción. Cuando Hibernate busca una entidad en un estado y encuentra la misma entidad pero ya la primera solicitud la cambió, arroja una excepción ya que no puede actualizar la entidad. Es como un conflicto en GIT.
• Tenía solicitudes automáticas (para monitorear la plataforma) que actualizan una entidad (y la reversión manual unos segundos más tarde). Pero esta plataforma ya es utilizada por un equipo de prueba. Cuando un probador realiza una prueba en la misma entidad que las solicitudes automáticas, (dentro de la misma centésima de milisegundo), obtengo la excepción. Como en el caso anterior, al salir de la segunda transacción, la entidad previamente recuperada ya ha cambiado.

Conclusión: en mi caso, no fue un problema que se puede encontrar en el código. Esta excepción se produce cuando Hibernate determina que la entidad primero fue extraída de la base de datos modificada durante la transacción actual , por lo que no puede vaciarla a la base de datos ya que Hibernate no sabe cuál es la versión correcta de la entidad: la actual búsqueda de transacciones al comienzo; o el que ya está almacenado en la base de datos.

Answer 6

En realidad, me pasa a mí cuando no almacené el objeto como variable de referencia. en la clase de Entidad. Como este código: ses.get(InsurancePolicy.class, 101); Después de eso, almacené el objeto en la variable de referencia de la entidad para que el problema se resolviera para mí. policy=(InsurancePolicy)ses.get(InsurancePolicy.class, 101); Después de eso, actualicé el objeto y funcionó bien.

Answer 7

Encontré este problema donde tuvimos una relación uno-muchos.

En el archivo hibernate hbm mapping para master, para object con set type arrangement, se agregó cascade="save-update" y funcionó bien.

Sin esto, de forma predeterminada, hibernate intenta actualizar para un registro inexistente y, al hacerlo, se inserta en su lugar.

Answer 8

Estaba enfrentando el mismo problema. El código estaba funcionando en el entorno de prueba. Pero no funcionaba en el entorno de ensayo.

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

El problema era que la tabla tenía una sola entrada para cada clave principal en la prueba de la tabla de DB. Pero en la puesta en escena de DB había una entrada múltiple para la misma clave primaria. (El problema está en la puesta en escena de DB, la tabla no tenía ninguna restricción de clave primaria, también había entrada múltiple).

Por lo tanto, cada vez que se realiza una operación de actualización falla. Intenta actualizar el registro individual y espera obtener el recuento de actualizaciones como 1. Pero dado que hubo 3 registros en la tabla para la misma clave principal, el recuento de actualizaciones de resultados encuentra 3. Dado que el recuento de actualizaciones esperadas y el recuento actual de actualizaciones de resultados no coinciden , Lanza una excepción y retrocede.

Después de eliminar todos los registros que tienen clave primaria duplicada y restricciones de clave principal agregadas. Está funcionando bien.

Hibernate - Batch update returned unexpected row count from update: 0 actual row count: 0 expected: 1

conteo de filas real: 0 // significa que no se encontró ningún registro para actualizar
actualización: 0 // significa que no se ha encontrado ningún registro, de modo que no hay actualizaciones
esperado: 1 // significa que se espera al menos 1 registro con la clave en la tabla db.

Aquí el problema es que la consulta intenta actualizar un registro para alguna clave, pero Hibernate no encontró ningún registro con la clave.

Answer 9

Estaba enfrentando esta excepción, e hibernación estaba funcionando bien. Traté de insertar manualmente un registro usando pgAdmin, aquí el problema quedó claro. La consulta de inserción SQL devuelve 0 insertar. y hay una función desencadenante que causa este problema porque devuelve nulo. así que solo tengo que configurarlo para que sea nuevo. y finalmente resolví el problema.

Espero que ayude a cualquier cuerpo.

Answer 10

Esto me pasó una vez por accidente cuando estaba asignando identificadores específicos a algunos objetos (pruebas) y luego intentaba guardarlos en la base de datos. El problema era que en la base de datos había una política específica para configurar los ID de los objetos. Simplemente no asigne una ID si tiene una política en el nivel de Hibernate.

Answer 11

Esto me pasa porque me falta la declaración de ID en la clase de frijoles.

Answer 12

Esto me sucedió a mí también, porque tenía mi ID como Long, y recibía de la vista el valor 0, y cuando traté de guardar en la base de datos obtuve este error, lo arreglé estableciendo el id en nulo.

Answer 13

Esto puede suceder cuando los disparadores ejecutan consultas DML (modificación de datos) adicionales que afectan los recuentos de filas. Mi solución fue agregar lo siguiente en la parte superior de mi disparador:

SET NOCOUNT ON;

Answer 14

Esto sucede cuando declaras el Bean administrado JSF como

@RequestScoped;

cuando deberías declarar como

@SessionScoped;

Saludos;

Answer 15

Esto sucedió si cambia algo en el conjunto de datos utilizando la consulta sql nativa, pero el objeto persistente para el mismo conjunto de datos está presente en el caché de la sesión. Use session.evict (yourObject);

Answer 16

Hibernate almacena en caché los objetos de la sesión. Si el objeto es accedido y modificado por más de 1 usuario, se puede org.hibernate.StaleStateException . Se puede resolver con el método de fusión / actualización de entidades antes de guardar o usar el bloqueo. Más información: http://java-fp.blogspot.lt/2011/09/orghibernatestalestateexception-batch.html

Answer 17

Me encontré con este problema cuando comencé manualmente y cometí transacciones dentro del método anotado como @Transactional . Solucioné el problema detectando si ya existía una transacción activa.

//Detect underlying transaction
if (session.getTransaction() != null && session.getTransaction().isActive()) {
myTransaction = session.getTransaction();
preExistingTransaction = true;
} else {
myTransaction = session.beginTransaction();
}

Luego permití que Spring se encargara de comprometer la transacción.

private void finishTransaction() {
if (!preExistingTransaction) {
try {
tx.commit();
} catch (HibernateException he) {
if (tx != null) {
tx.rollback();
}
log.error(he);
} finally {
if (newSessionOpened) {
SessionFactoryUtils.closeSession(session);
newSessionOpened = false;
maxResults = 0;
}
}
}
}

Answer 18

Obtuve este error cuando intenté actualizar un objeto con una identificación que no existía en la base de datos. La razón de mi error fue que había asignado manualmente una propiedad con el nombre ''id'' a la representación JSON del lado del cliente del objeto y luego al deserializar el objeto en el lado del servidor esta propiedad ''id'' sobrescribiría la variable de instancia ( también llamado ''id'') que se suponía que Hibernate debía generar. Así que tenga cuidado de nombrar colisiones si está usando Hibernate para generar identificadores.

Answer 19

Obtuve la misma excepción al eliminar un registro por Id que no existe en absoluto. Así que verifique que el registro que está actualizando / borrando realmente exista en DB

Answer 20

Sin códigos y mapeos para sus transacciones, será casi imposible investigar el problema.

Sin embargo, para obtener un mejor manejo de las causas del problema, intente lo siguiente:

• En su configuración de hibernación, establezca hibernate.show_sql en verdadero. Esto debería mostrarle el SQL que se ejecuta y causa el problema.
• Establezca los niveles de registro para Spring e Hibernate en DEBUG, nuevamente esto le dará una mejor idea de qué línea causa el problema.
• Cree una prueba unitaria que replique el problema sin configurar un administrador de transacciones en Spring. Esto debería darle una mejor idea de la línea ofensiva de código.

Espero que ayude.

Answer 21

Solución: en el archivo de mapeo de Hibernate para la propiedad id, si usa cualquier clase de generador, para esa propiedad no debe establecer el valor explícitamente utilizando un método setter.

Si establece el valor de la propiedad Id explícitamente, generará el error anterior. Marque esto para evitar este error. o Es un error mostrar cuando mencionas en el archivo de mapeo el generador de campo = "nativo" o "incremental" y en tu BASE DE DATOS la tabla mapeada no está autoincrementada Solución: Ve a tu BASE DE DATOS y actualiza tu tabla para establecer autoincremento

Answer 22

También me encontré con el mismo desafío. En mi caso, estaba actualizando un objeto que ni siquiera existía, utilizando hibernateTemplate .

En realidad, en mi aplicación estaba obteniendo un objeto DB para actualizar. Y al actualizar sus valores, también actualicé su ID por error, y seguí adelante para actualizarlo y encontré dicho error.

Estoy usando hibernateTemplate para las operaciones CRUD.

Answer 23

También puede suceder cuando intenta UPDATE una LLAVE PRINCIPAL .

Answer 24

Tengo el mismo problema y verifiqué que esto puede ocurrir debido a la tecla principal de incremento automático. Para resolver este problema, no inserte el valor de incremento automático con el conjunto de datos. Inserta datos sin la clave principal.

Answer 25

Uno de los casos

SessionFactory sf=new Configuration().configure().buildSessionFactory();
Session session=sf.openSession();
UserDetails user=new UserDetails();
session.beginTransaction();
user.setUserName("update user agian");
user.setUserId(12);
session.saveOrUpdate(user);
session.getTransaction().commit();
System.out.println("user::"+user.getUserName());
sf.close();

Answer 26

sucede cuando intentas eliminar el mismo objeto y luego otra vez actualizar el mismo objeto, usar esto después de eliminar

session.clear ();

Answer 27

Id(x => x.Id, "id").GeneratedBy.**Assigned**(); este error porque Id(x => x.Id, "id").GeneratedBy.**Assigned**(); erróneamente la columna ID usando Id(x => x.Id, "id").GeneratedBy.**Assigned**();

Problema resuelto al usar Id(x => x.Id, "id").GeneratedBy.**Identity**();