Persistencia con EJB3

Hola. Necesito ayuda.
Actualmente estoy desarrollando una aplicacion en Struts 1.3, EJB3 y Websphere. La persistencia mediante toplink y me encuentro en la necesidad de:
Persistir un Objeto con manejo de transaccion. Lo he implementado , guardando parcialmente el contenido del objeto , solo que tengo un timeout por el contenedor, ya que la informacion es abundante y accedemos en multiples veces a la BD. Actualmente la transacion tarda 6 minutos. Algo fuera de lo razonable.

Como alternativa de implementacion , tratamos de cargar de una sola vez el Objeto por persistir y hacer un merge unico. Solo que encontramos excepciones. El motivo es que el entity manager, esta intentando guardar los elementos hijos (Objetos anidados), antes que los elementos padre (Objetos anidados), contenidos en nuestro objeto.

Preguntas:
1.- ¿Hay una manera de indicarle al entity manager el orden en que deba hacer el merge? Entenderiamos que el entity manger tiene todas las relaciones , de manera de persistir completamente el objeto.

2.- ¿Hay otra tecnica para persistir objetos con multiples relaciones de una sola vez , optimizando el tiempo de persistencia?

Saludos. Gracias por las aportaciones.
Jesus Enrique Aldana Sanchez.

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de Nopalin

¿Buen diseño?

Según leo, tienes un objeto (padre) y lo persistes, luego creas otros objetos (hijos) los cuales tienen una propiedad que relaciona con padre y los persistes. En otro lado traes el objeto padre y modificas info, así como la de los hijos, al momento de que el orm hace el update te marca al actualizar primero los hijos que el padre?

Esto no deberia ocurrir, por que se supone que el objeto padre tiene un id único e inmutable y los hijos apuntan a este id. Modificar cualquier otra propiedad ya sea del padre o de los hijos no deberia generarte errores del tipo relacionales, a menos que los errores sean por constraints en las propiedades de los mismos. Te pido de favor si puedes postear el starcktrace generado cuando se hace el commit.

Ahora, las respuestas a tus preguntas:
1.- No, que yo sepa la api de persistencia no se preocupa por esto, se lo deja al orm.
2.- Pues los inserts y updates son generalmente lo más rapido, no llevando mas de 5 segundos en bases donde existen varios cientos de miles de registros, no se si se pueda optimizar éste tiempo de alguna forma, por que no pones que el toplink logee todos los queries que realiza, luego los realizas directo en la bd y checas donde es lo tardado, si del lado del ORM o del lado de la base de datos.

sobres

Imagen de ezamudio

updates e inserts

Los udpates e inserts pueden tardar mucho en tablas grandes dependiendo de los índices que existan. cuando digo "mucho" hablo de por ejemplo 50ms, de modo que solamente puedes hacer 20 inserts por segundo, lo cual es muy lento...