[SOLUCIONADO] Actualización muy lenta MySQL JPA

[Link_OOT]

Hola,

He hecho una aplicación que mediante JPA se conecta a una BBDD MySQL para la gestión de clientes. Cuando hay pocos clientes (menos de 1000) la actualización de clientes se hace de forma instantánea, pero cuando he realizado una prueba con casi 40.000 clientes, la actualización es tan lenta que hace inviable el uso de la aplicación.

¿Como puedo actualizar para que no sea tan lenta? ¿Hay alguna forma de mantener esos datos en caché y que la escritura en disco sea mas tarde?

Edito y añado el contenido del archivo persistence.xml

Código:

<persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
	<persistence-unit name="GestionServidorDefinitivo" transaction-type="RESOURCE_LOCAL">
	    <provider>org.apache.openjpa.persistence.PersistenceProviderImpl</provider>
		<class>model.Estado</class>
		<class>model.EstadoPK</class>
		<class>model.Visita</class>
		<class>model.Registro</class>
		<class>model.Cliente</class>
		<class>model.Comercial</class>
		<properties>
		    <property name="openjpa.RuntimeUnenhancedClasses" value="supported"/>
		    <property name="openjpa.ConnectionDriverName" value="com.mysql.jdbc.Driver"/>
		    <property name="openjpa.ConnectionURL" value="jdbc:mysql://127.0.0.1:3306/gestiondefinitivo"/>
		    <property name="openjpa.ConnectionUserName" value="user"/>
		    <property name="openjpa.ConnectionPassword" value="password"/>
		    <property name="openjpa.Multithreaded" value="true"/>
		</properties>
	</persistence-unit>
</persistence>

Gracias.

[MarronsDispatcher]

Viendo el persistence.xml no se puede tener claro casi nada.

¿ Puedes copiar el código que se encarga de actualizar los 40.000 clientes ?

Saludos.

[Link_OOT]

Iniciado por MarronsDispatcher

Viendo el persistence.xml no se puede tener claro casi nada.

¿ Puedes copiar el código que se encarga de actualizar los 40.000 clientes ?

Saludos.

No es actualizar los 40000 clientes, es actualizar uno en concreto cuando hay 40.000 clientes en la tabla. El código es este:

Código:

	public boolean editarCliente(@WebParam(name = "clienteOld") String clienteOld){
		m_log.info("EDITANDO CLIETNE");
		Gson gson = new Gson();
		Cliente clienteEdit = gson.fromJson(clienteOld, Cliente.class);
		if (em.getTransaction().isActive()) {
			em.joinTransaction();
		} else {
			em.getTransaction().begin();
		}
		try {
			em.merge(clienteEdit);
			em.getTransaction().commit();
			m_log.info("CLIENTE EDITADO CORRECTAMENTE");
			return true;
		} catch (Exception e) {
			m_log.info("NO SE HA EDITADO EL CLIETNE");
			m_log.info(e1.getMessage());
			return false;
		}
	}

Saludos.

[MarronsDispatcher]

Uff que raro, no son para nada una cantidad millonaria de registros, yo he tenido que realizar actualizaciones de más de medio millón de registros uno por uno porque cada uno tenía sus peculiaridades y te puedo asegurar que el rendimiento de JPA es bastante aceptable, realizando miles de operaciones sobre BBDD en segundos, no entiendo como un simple merge puede dar estos problemas, pero al turrón!!!

¿ Porque elegiste manejar tu mismo las transacciones ? Veo que tienes un WebParam y JSON, entiendo que será un WebService que modifica un cliente, por lo que tendrás un servidor de aplicaciones y un contenedor que gustosamente gestionará las transacciones por ti, evitandote begins,commits ... y toda esas cositas que tienes por ahí, bueno concretamente me refería a tu RESOURCE_LOCAL. También deberías configurar obviamente el JNDI en el servidor de aplicaciones.

Es difícil medir el rendimiento de una transacción cuando...no se sabe nada acerca de las tablas que gestionas, los tipos de datos, indices... etc Si puedes añadir algo de información al respecto...lo agradecería.

No veo en tu persistence.xml nada referente a :

Código Java:

<property name = "hibernate.show_sql" value = "true" />
 

Si tienes problemas con las sentencias que ejecutas contra BBDD, sería bueno poder ver las consultas/updates que realiza JPA contra la BBDD, al menos durante la fase de desarrollo, y así podrás lanzar esas consultas en el cliente y ver cuanto tardan realmente. Recordar que cuando JPA realiza un merge, lo primero que realiza es una consulta contra tu BBDD y también podría ser que tu Entity Cliente tuviera relaciones con otras tablas y JPA con la consulta previa al update te las estuviera recogiendo también.

Resumiendo, revisa el tema de quien gestiona las transacciones, es mejor que dejárselo al contenedor, y aunque le des el control, puedes modificar la transaccionalidad en determinadas operaciones o hacer que incluso algunas operaciones no sean transaccionales (ganas muchísimo tiempo), sobre todo operativas que requieran únicamente lectura contra BBDD, o no te importe que tu BBDD pueda ser inconsistente jeje.

Con el show_sql, podrás ver que sentencias se están ejecutando contra BBDD, recógelas y lánzalas desde un cliente contra la BBDD, y verás si el problema lo tienes con el merge().

Si la consulta que realiza JPA para hacer el merge es lenta, y por lo tanto queda confirmada tu teoría, realiza EXPLAIN PLAN sobre tus sentencias para ver donde pierdes tiempo, tal vez la consulta no este optimizada, o no tengas indices, o yo que se, quien me dice a mi, que tu PK no es un String ejejej.

Ya siento no poder decirte más, con las tablas, la consulta + update de JPA y teniendo algunos tiempos(Desglosa JSON y el merge y evalua cuanto tarda cada uno) podría darte más información.

Saludos!!!!!

[Link_OOT]

Ahora mismo no puedo realizar todas las pruebas que comentas, tendrá que ser esta tarde, lo que si puedo mirar es los tipos de datos de la clase que son los mismos que los de la tabla

Código:

@Entity
@Table(name="cliente")
@NamedQueries({
    @NamedQuery(name = "Cliente.findAll", query = "SELECT a FROM Cliente a"),
    @NamedQuery(name = "Cliente.findByNombre", query = "SELECT a FROM Cliente a WHERE a.nombreRazonSocial = :nombre"),
    @NamedQuery(name = "Cliente.findByCifNif", query = "SELECT a FROM Cliente a WHERE a.cif = :cif")})
public class Cliente implements Serializable {
	private static final long serialVersionUID = 1L;

	@Id
	@Column(unique=true, nullable=false)
	private BigInteger id;

	@Column(unique=true, nullable=false, length=50)
	private String cif;

	@Column(length=50)
	private String codigoPostal;

	@Lob
	private String comentarios;

	@Column(length=50)
	private String concertador;

	@Column(length=500)
	private String direccion;

	@Column(length=100)
	private String email;

	@Column(length=50)
	private String gerente;
        

	private int lineasFijo;

	private int lineasMovil;

	@Column(length=50)
	private String localidad;

	@Column(length=50)
	private String nombreRazonSocial;

	@Column(length=20)
	private String numeroCuenta;

	@Column(length=50)
	private String operadorFijo;

	@Column(length=50)
	private String operadorMovil;

	@Column(length=50)
	private String permanenciaFijo;

	@Column(length=50)
	private String permanenciaMovil;

	@Column(length=100)
	private String personaContacto;

	@Column(length=50)
	private String provincia;

	@Column(length=50)
	private String segmento;

	@Column(length=50)
	private String telefono;

	@Column(length=50)
	private String telefonoContacto;

	@Column(length=10)
	private String telefonos;

	
	@OneToMany
	@JoinColumn(name="DNICliente")
	private List<Telefono> telefonosSet;

 //Getters y Setters

[Link_OOT]

He estado probando algunas cosas que he leido por internet, y ahora no se que he tocado que cuando intento editar un registro (la tabla está relacionada con la tabla clientes) me sale el siguiente error:

Código:

ID: 8
Address: http://localhost:8080/GestionServidorDefinitivo2/services/ServicioWebPort
Encoding: UTF-8
Http-Method: POST
Content-Type: application/soap+xml; action="urn:GuardarRegistro"; charset=UTF-8
Headers: {Accept=[*/*], cache-control=[no-cache], connection=[keep-alive], Content-Length=[1078], content-type=[application/soap+xml; action="urn:GuardarRegistro"; charset=UTF-8], host=[localhost:8080], pragma=[no-cache], user-agent=[Apache CXF 2.7.4]}
Payload: <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"><soap:Body><ns2:guardarRegistro xmlns:ns2="http://main.servicioweb.es/"><arg0>{"IDRegistro":1371587409723,"comentarios":"","concertador":"PEPE","cliente":{"cif":"12345678Z","codigoPostal":"12345","comentarios":"","direccion":" ","email":"","gerente":"","id":1371587409723,"lineasFijo":0,"lineasMovil":0,"localidad":"MADRID","nombreRazonSocial":"","numeroCuenta":"00000000000000000000","operadorFijo":"","operadorMovil":"","personaContacto":"12345678Z","provincia":"MADRID","segmento":"","telefonoContacto":"123456789","telefonosSet":[{"id":{"DNICliente":"12345678Z","telefono":"123456789"}},{"id":{"DNICliente":"12345678Z","telefono":"123456789"}},{"id":{"DNICliente":"12345678Z","telefono":"123456789"}}]},"IDEstado":19,"NLineasFijo":0,"NLineasMovil":0,"nombreEstado":"Cliente Abierto","operadorFijo":"","operadorMovil":"","permanenciaFijo":"","permanenciaMovil":""}</arg0></ns2:guardarRegistro></soap:Body></soap:Envelope>
--------------------------------------
nov 19, 2013 6:52:08 PM es.servicioweb.main.ServicioWeb guardarRegistro
INFO: GUARDANDO REGISTRO DE UN CLIENTE
61336  GestionServidorDefinitivo  TRACE  ["http-bio-8080"-exec-1] openjpa.jdbc.SQL - <t 214129666, conn 1107386637> executing prepstmnt 580539394 SELECT t0.IDRegistro, t0.IDEstado, t0.NLineasFijo, t0.NLineasMovil, t1.cif, t1.codigoPostal, t1.comentarios, t1.concertador, t1.direccion, t1.email, t1.gerente, t1.id, t1.lineasFijo, t1.lineasMovil, t1.localidad, t1.nombreRazonSocial, t1.numeroCuenta, t1.operadorFijo, t1.operadorMovil, t1.permanenciaFijo, t1.permanenciaMovil, t1.personaContacto, t1.provincia, t1.segmento, t1.telefono, t1.telefonoContacto, t1.telefonos, t0.comentarios, t0.concertador, t0.fechaCreacion, t0.fechaModificacion, t0.nombreEstado, t0.operadorFijo, t0.operadorMovil, t0.origen, t0.permanenciaFijo, t0.permanenciaMovil FROM registros t0 LEFT OUTER JOIN Cliente t1 ON t0.DNICLiente = t1.cif WHERE (t0.DNICLiente = ?) [params=(String) 12345678Z]
61336  GestionServidorDefinitivo  TRACE  ["http-bio-8080"-exec-1] openjpa.jdbc.SQL - <t 214129666, conn 1107386637> [0 ms] spent
61341  GestionServidorDefinitivo  TRACE  ["http-bio-8080"-exec-1] openjpa.jdbc.SQL - <t 214129666, conn 2121972292> executing prepstmnt 733672017 SELECT t0.IDRegistro, t0.IDEstado, t0.NLineasFijo, t0.NLineasMovil, t1.cif, t1.codigoPostal, t1.comentarios, t1.concertador, t1.direccion, t1.email, t1.gerente, t1.id, t1.lineasFijo, t1.lineasMovil, t1.localidad, t1.nombreRazonSocial, t1.numeroCuenta, t1.operadorFijo, t1.operadorMovil, t1.permanenciaFijo, t1.permanenciaMovil, t1.personaContacto, t1.provincia, t1.segmento, t1.telefono, t1.telefonoContacto, t1.telefonos, t0.comentarios, t0.concertador, t0.fechaCreacion, t0.fechaModificacion, t0.nombreEstado, t0.operadorFijo, t0.operadorMovil, t0.origen, t0.permanenciaFijo, t0.permanenciaMovil FROM registros t0 LEFT OUTER JOIN Cliente t1 ON t0.DNICLiente = t1.cif WHERE (t0.DNICLiente = ?) [params=(String) 12345678Z]
61341  GestionServidorDefinitivo  TRACE  ["http-bio-8080"-exec-1] openjpa.jdbc.SQL - <t 214129666, conn 2121972292> [0 ms] spent
nov 19, 2013 6:52:49 PM org.apache.cxf.phase.PhaseInterceptorChain doDefaultLogging
WARNING: Application {http://main.servicioweb.es/}ServicioWebService#{http://main.servicioweb.es/}guardarRegistro has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:162)
	at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.createFault(AbstractJAXWSMethodInvoker.java:213)
	at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:128)
	at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.invoke(AbstractJAXWSMethodInvoker.java:178)
	at org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:68)
	at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:75)
	at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58)
	at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
	at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
	at java.util.concurrent.FutureTask.run(Unknown Source)
	at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
	at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:107)
	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:271)
	at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
	at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:239)
	at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:223)
	at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:203)
	at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:137)
	at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:158)
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:243)
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:163)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:641)
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:219)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:164)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:462)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:562)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:395)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:250)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:188)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:166)
	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:302)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.StackOverflowError
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.openjpa.enhance.Reflection.getDeclaredField(Reflection.java:267)
	at org.apache.openjpa.enhance.Reflection.findField(Reflection.java:246)
	.........
	nov 19, 2013 6:52:49 PM org.apache.cxf.binding.soap.interceptor.Soap12FaultOutInterceptor$Soap12FaultOutInterceptorInternal handleMessage
INFO: class org.apache.cxf.binding.soap.interceptor.Soap12FaultOutInterceptor$Soap12FaultOutInterceptorInternalapplication/soap+xml
nov 19, 2013 6:52:49 PM org.apache.cxf.services.ServicioWebService.ServicioWebPort.ServicioWeb
INFO: Outbound Message
---------------------------
ID: 8
Response-Code: 500
Encoding: UTF-8
Content-Type: application/soap+xml
Headers: {}
Payload: <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"><soap:Body><soap:Fault><soap:Code><soap:Value>soap:Receiver</soap:Value></soap:Code><soap:Reason><soap:Text xml:lang="en">Fault occurred while processing.</soap:Text></soap:Reason></soap:Fault></soap:Body></soap:Envelope>
--------------------------------------

¿Como lo arreglo?

Gracias.

[MarronsDispatcher]

Iniciado por Link_OOT

y ahora no se que he tocado

Mal comenzamos

Código Java:

Caused by: java.lang.StackOverflowError
 

Normalmente, aunque puede haber más motivos, se suele producir cuando te llamas a ti mismo, y lo por lo tanto, no obtienes nunca salida a tu método. (Debugear suele ser la mejor opción).

Código Java:

LEFT OUTER JOIN Cliente t1 ON t0.DNICLiente = t1.cif WHERE (t0.DNICLiente = ?) [params=(String) 12345678Z
 

¿Esa query corresponde a la sentencia previa de JPA a la merge que me comentabas antes? En la clausula WHERE filtras por un String, cualquier query que filtre por un String, suele penalizar mucho.

Esa LEFT OUTER JOIN...que tipo de relación es ? one to many? one to one? Sin tener ni idea de tu respuesta, normalmente el rendimiento mejora con una LEFT OUTER JOIN FETCH, nos evitamos que JPA realice sub-consultas por cada registro de la relación.

Saludos.

[Link_OOT]

Iniciado por MarronsDispatcher

Código Java:

Caused by: java.lang.StackOverflowError
 

Normalmente, aunque puede haber más motivos, se suele producir cuando te llamas a ti mismo, y lo por lo tanto, no obtienes nunca salida a tu método. (Debugear suele ser la mejor opción).


Saludos.

He cortado la excepción porque era muy larga y eran todo clases que estaban en el paquete de las dos últimas líneas.

Iniciado por MarronsDispatcher

Código Java:

LEFT OUTER JOIN Cliente t1 ON t0.DNICLiente = t1.cif WHERE (t0.DNICLiente = ?) [params=(String) 12345678Z
 

¿Esa query corresponde a la sentencia previa de JPA a la merge que me comentabas antes? En la clausula WHERE filtras por un String, cualquier query que filtre por un String, suele penalizar mucho.

Esa LEFT OUTER JOIN...que tipo de relación es ? one to many? one to one? Sin tener ni idea de tu respuesta, normalmente el rendimiento mejora con una LEFT OUTER JOIN FETCH, nos evitamos que JPA realice sub-consultas por cada registro de la relación.

Saludos.

Tengo que actualizar ese registro, que esta enlazado a un cliente en una relación One to One. Para buscar el cliente busco por DNI que tiene que ser string.

Estoy intentando cambiar el persistence.xml para usar JTA, a ver si consigo que mejore el rendimiento

Usando RESOURCE_LOCAL en el persistence.xml he lanzado una consulta "global" contra la tabla registros (también tiene sobre 40.000 filas), si la lanzo desde un gestor de BBDD como HeidiSQL tarda en ejecutarse 0.047seg, sin embargo, en el servidor obtengo los siguientes resultados:

Codigo que se ejecuta:

Código:

                                q = em.createQuery("SELECT pro FROM Registro pro WHERE pro.IDEstado NOT IN (20)");
				long tiempo1=System.currentTimeMillis();
				List<Registro> lista = q.getResultList();
				System.out.println("Tiempo: " +Long.toString(System.currentTimeMillis()-tiempo1));

El resultado obtenido es:

Código:

11445  GestionServidorDefinitivo  TRACE  ["http-bio-8080"-exec-3] openjpa.jdbc.SQL - <t 811381485, conn 245066937> executing prepstmnt 272440927 SELECT t0.IDRegistro, t0.IDEstado, t0.NLineasFijo, t0.NLineasMovil, t1.cif, t1.codigoPostal, t1.comentarios, t1.concertador, t1.direccion, t1.email, t1.gerente, t1.id, t1.lineasFijo, t1.lineasMovil, t1.localidad, t1.nombreRazonSocial, t1.numeroCuenta, t1.operadorFijo, t1.operadorMovil, t1.permanenciaFijo, t1.permanenciaMovil, t1.personaContacto, t1.provincia, t1.segmento, t1.telefono, t1.telefonoContacto, t1.telefonos, t0.comentarios, t0.concertador, t0.fechaCreacion, t0.fechaModificacion, t0.nombreEstado, t0.operadorFijo, t0.operadorMovil, t0.origen, t0.permanenciaFijo, t0.permanenciaMovil FROM registros t0 LEFT OUTER JOIN Cliente t1 ON t0.DNICLiente = t1.cif WHERE (NOT (t0.IDEstado = ?) AND t0.IDEstado IS NOT NULL) [params=(long) 20]
11686  GestionServidorDefinitivo  TRACE  ["http-bio-8080"-exec-3] openjpa.jdbc.SQL - <t 811381485, conn 245066937> [241 ms] spent
nov 19, 2013 10:51:52 PM es.servicioweb.main.ServicioWeb contarRegistrosCif
INFO: CLIENTES LISTADOS
Tiempo: 7800

Hay algo que me esta ralentizando muchísimo la aplicación, pero no se me ocurre que puede ser
Saludos.

[MarronsDispatcher]

Que query lanzaste en HeidiSQL?

¿Esta?

Código Java:

SELECT t0.IDRegistro, t0.IDEstado, t0.NLineasFijo, t0.NLineasMovil, t1.cif, t1.codigoPostal, t1.comentarios, t1.concertador, t1.direccion, t1.email, t1.gerente, t1.id, t1.lineasFijo, t1.lineasMovil, t1.localidad, t1.nombreRazonSocial, t1.numeroCuenta, t1.operadorFijo, t1.operadorMovil, t1.permanenciaFijo, t1.permanenciaMovil, t1.personaContacto, t1.provincia, t1.segmento, t1.telefono, t1.telefonoContacto, t1.telefonos, t0.comentarios, t0.concertador, t0.fechaCreacion, t0.fechaModificacion, t0.nombreEstado, t0.operadorFijo, t0.operadorMovil, t0.origen, t0.permanenciaFijo, t0.permanenciaMovil FROM registros t0 LEFT OUTER JOIN Cliente t1 ON t0.DNICLiente = t1.cif WHERE (NOT (t0.IDEstado = ?) AND t0.IDEstado IS NOT NULL)
 

o esta

Código Java:

SELECT pro FROM Registro pro WHERE pro.IDEstado NOT IN (20)
 

Te lo comento porque son distinstas querys, en la primera, por cada registro te estás trayendo su cliente, en las relaciones OneToOne, por defecto el FetchType es EAGER, y JPA irá a buscar cada cliente por cada registro que tengas en BBDD.

Si estas ejecutando la segunda query, solo estás recuperando los registros.

Independientemente de esto, y recapitulando, en vez de hacer un merge, que te va a realizar la SELECT + UPDATE, puedes utilizar NamedQuery, las namedQuery se suelen definir en los Entity, creas una namedQuery que haga la UPDATE directamente, te saltas la SELECT y a correr jeje.

Lo he escrito a pelo, sin IDE, puede escaparseme algun caracter.

Código Java:

Query query = em.createNamedQuery("nombreNamedQuery");
query.setParameter("miParametro", miValor);
 
quer.executeUpdate();
 

Saludos.

[Link_OOT]

He ejecutado la 2º consulta, la he modificado para que se crucen los datos con los DNIs de la tabla clientes y ha tardado 0,118 seg según HeidiSQL

También he probado lo de poner las namedQueries y sigue tardando mas o menos lo mismo.

Yendo a la desesperada he hecho la conexión a pelo y lo hace de forma inmediata... pero es una chapuza... no es plan de dejarlo así

Código:

try {
					long tiempo1=System.currentTimeMillis();
					Connection conexion = DriverManager.getConnection("jdbc:mysql://localhost/gestiondefinitivo", "user", "password");
					PreparedStatement stmt2 = conexion.prepareStatement("UPDATE Registros reg SET "
				    		+ "reg.comentarios='"+registroNuevo.getComentarios()+"', reg.IDEstado='"+registroNuevo.getIDEstado()+"', reg.nombreEstado='"+registroNuevo.getNombreEstado()+"', reg.operadorMovil='"+registroNuevo.getOperadorMovil()+"',"
				    		+ " reg.NLineasMovil='"+registroNuevo.getNLineasMovil()+"', reg.permanenciaMovil='"+registroNuevo.getPermanenciaMovil()+"', reg.operadorFijo='"+ registroNuevo.getOperadorFijo()+"', reg.permanenciaFijo='"+registroNuevo.getPermanenciaFijo()+"',"
				    		+ " reg.NLineasFijo='"+ registroNuevo.getNLineasFijo()+"', reg.concertador='"+registroNuevo.getConcertador()+"', reg.origen='"+registroNuevo.getOrigen()+"', reg.fechaModificacion='"+Calendar.getInstance().get(Calendar.DATE)+ "-"+ Integer.toString((Calendar.getInstance().get(Calendar.MONTH)) + 1)+ "-"+ Calendar.getInstance().get(Calendar.YEAR)+"' WHERE reg.IDRegistro="+(resultado.get(0)).getIDRegistro());
					int result=stmt2.executeUpdate();
					stmt2.close();
					conexion.close();
					System.out.println("Tiempo: " +Long.toString(System.currentTimeMillis()-tiempo1));
				} catch (SQLException e) {
					e.printStackTrace();
				}

Además, no se como se comportara ese código cuando haya concurrencia (nunca va a estar sobre el mismo cliente o registro, pero si se pueden estar editando 10 registros a la vez)

Saludos.

[Link_OOT]

Al final he pasado de JPA, utilizo el driver jdbc directamente y funciona muy bien, la mejora del rendimiento es espectacular.

Muchas a gracias por el interés que habéis mostrado con este problema. :D

Saludos