Struts² portlet problems with reading from and writing to DB2 database

[Kristof Verbraeken, modificado 12 Anos atrás.]

Hello everyone,

I'm experiencing a nasty problem with a Struts² portlet at the moment using a service created with the Liferay Service Builder.

We're using a Liferay 5.2.3 setup on a staging and production environment, which are both identical to each other. The only difference is that they are using different DB2 databases, but all tables and permissions are equal.

Other specifications:

• Windows Server 2003
• Liferay 5.2.3 Community Edition
• IBM DB2 9.7
• Plugins are made using Struts and Struts² using services generated with the Liferay Service Builder
• JBoss 5.1.0

We've deployed the portlet on the staging environment first and it worked fine. We've let our client fill in all the data on this environment too. After putting everything in production we've let an external database administrator copy all the data from staging to production. Both tables are identical in regards of data types, data lengths and constraints. The data was copied successfully, but reading the table or writing to the table seems to cause some problems in production.

Stack trace:

2012-01-04 19:13:43,773 ERROR [portal-web.docroot.html.portal.render_portlet.jsp] com.liferay.portal.kernel.dao.orm.ORMException: Could not execute JDBC batch update at com.liferay.portal.dao.orm.hibernate.ExceptionTranslator.translate(ExceptionTranslator.java:41) at com.liferay.portal.dao.orm.hibernate.SessionImpl.flush(SessionImpl.java:122) at com.liferay.portal.service.persistence.BatchSessionImpl.update(BatchSessionImpl.java:75) at com.liferay.portal.service.persistence.BatchSessionUtil.update(BatchSessionUtil.java:53) at be.anonymous.portlet.sessions.service.persistence.SessionsItemPersistenceImpl.updateImpl(SessionsItemPersistenceImpl.java:216) at be.anonymous.portlet.sessions.service.persistence.SessionsItemPersistenceImpl.update(SessionsItemPersistenceImpl.java:195) at be.anonymous.portlet.sessions.service.base.SessionsItemLocalServiceBaseImpl.addSessionsItem(SessionsItemLocalServiceBaseImpl.java:27) at be.anonymous.portlet.sessions.service.SessionsItemLocalServiceUtil.addSessionsItem(SessionsItemLocalServiceUtil.java:34) at be.anonymous.portlet.sessions.admin.action.SessionPostAction.execute(SessionPostAction.java:34) at com.opensymphony.xwork2.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:440) at com.opensymphony.xwork2.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:279) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:242) at com.opensymphony.xwork2.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:163) at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236) at com.opensymphony.xwork2.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:249) at org.apache.struts2.interceptor.validation.AnnotationValidationInterceptor.doIntercept(AnnotationValidationInterceptor.java:68) at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236) at com.opensymphony.xwork2.interceptor.ConversionErrorInterceptor.intercept(ConversionErrorInterceptor.java:122)

The ORMException can mean many things and I've searched for topics regarding this exception, but the solutions and/or situations were different from ours.

The last line in the stack trace makes me think it has something to do with the data itself, although both tables on staging and production are identical as said before.

Unfortunately I cannot access the DB2 logs itself through CLI (no permissions).

Has someone experienced the same situation before or can someone give me any more tips to solve this horrible problem?

Thanks in advance.

Kind regards,
Kristof

[Kristof Verbraeken, modificado 12 Anos atrás.]

Bump to mention some extra details.

I've found in several other topics that this problem is mostly resolved by restarting the application server, but unfortunately this isn't the case here...