[
http://jira.jboss.com/jira/browse/JBAS-3923?page=comments#action_12355634 ]
Marius Kotsbak commented on JBAS-3923:
--------------------------------------
I don't think we have tested in without read-only=false.
We can only see this when using no transaction (trans=NotSupported) combined with commit
option B (default).
That combination gives a lot of database access, getting the whole row again for each code
line like bean.getAttributeA, bean.getAttributeB etc. Anyway it should not fail though.
Changing to commit option A/D or adding transaction reduces the database access, but it
might then not fail because of the less traffic on the database part.
CMP mixing database columns on high load
----------------------------------------
Key: JBAS-3923
URL:
http://jira.jboss.com/jira/browse/JBAS-3923
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: CMP service
Affects Versions: JBossAS-4.0.5.GA
Environment: -Debian Linux sarge (stable)
-Postgresql 8.1.4
-jdbc driver postgresql-8.1-407.jdbc3.jar
Reporter: Marius Kotsbak
Assigned To: Alexey Loubyansky
This exception appears on high load (stress testing) of a product on JBoss 4.0.5:
2006-12-04 17:46:06,732 ERROR [org.jboss.ejb.plugins.LogInterceptor] EJBException in
method: public abstract no.boostcom.sms
fusion.beans.RecurringDataLocal
no.boostcom.smsfusion.beans.InboxLocal.getRecurringData(), causedBy:
org.postgresql.util.PSQLException: Bad value for type timestamp : active
at org.postgresql.jdbc2.TimestampUtils.loadCalendar(TimestampUtils.java:232)
at org.postgresql.jdbc2.TimestampUtils.toTimestamp(TimestampUtils.java:307)
at
org.postgresql.jdbc2.AbstractJdbc2ResultSet.getTimestamp(AbstractJdbc2ResultSet.java:419)
at
org.postgresql.jdbc2.AbstractJdbc2ResultSet.getTimestamp(AbstractJdbc2ResultSet.java:2088)
at
org.jboss.resource.adapter.jdbc.WrappedResultSet.getTimestamp(WrappedResultSet.java:943)
at
org.jboss.ejb.plugins.cmp.jdbc.JDBCResultSetReader$12.readResult(JDBCResultSetReader.java:255)
at
org.jboss.ejb.plugins.cmp.jdbc.JDBCResultSetReader$AbstractResultSetReader.get(JDBCResultSetReader.java:500)
at
org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadArgumentResults(JDBCAbstractCMPFieldBridge.j
ava:482)
at
org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadArgumentResults(JDBCAbstractCMPFieldBridge.j
ava:432)
at
org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadInstanceResults(JDBCAbstractCMPFieldBridge.j
ava:393)
at
org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:207)
at
org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:88)
at
org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManager.java:646)
at
org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManager.java:628)
at
org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity(CMPPersistenceManager.java:406)
at
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.loadEntity(CachedConnectionInterceptor.java:252)
at
org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchronizationInterceptor.java:243)
at
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158)
at
org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke(EntityReentranceInterceptor.java:126)
at
org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:276)
at
org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:104)
at
org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:68)
at
org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
at
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:378)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
at
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:168)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
at
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:136)
at org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:520)
at org.jboss.ejb.Container.invoke(Container.java:954)
at
org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:430)
The value "active" is valid for another column in the same entity bean than the
timestamp column JBoss is trying to use it on.
We see other similar stacktraces:
2006-12-04 17:46:12,884 ERROR [org.jboss.ejb.plugins.LogInterceptor]
TransactionRolledbackLocalException in method: public a
bstract boolean
no.boostcom.smsfusion.smsfusionReceiverBeans.MtextHelperLocal.storeSMS(no.polardesign.boostcom.sms.SMSInnMel
ding,no.boostcom.smsfusion.beans.InboxVO) throws
javax.ejb.ObjectNotFoundException,javax.naming.NamingException,javax.ejb.Fi
nderException,javax.ejb.CreateException, causedBy:
org.postgresql.util.PSQLException: Bad value for type timestamp : WAP Ordbok
at org.postgresql.jdbc2.TimestampUtils.loadCalendar(TimestampUtils.java:232)
Here another column is exchanged with the timestamp column.
Removing the CMRs between all related CMP beans (which also removes locking) seems to
remove this problem, but that can result in much work. Get-fields in the entity beans are
set to read only to reduce locking.
The same code worked fine on JBoss 3.2.5 using the same stress tests. It is also working
on JBoss 4.0.5 during single accesses (not multitasking).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira