It isn't necessarily that simple. Since the previous error didn't
generate a stack trace, it was presumably caught and handled as an
"expected" issue. The problem may be that other database products
tolerate execution of further statements after an exception, and the
framework is assuming such behavior.
I've seen cases where the transaction is automatically rolled back by
the database product in response to some problems, allowing statements
to proceed under a new database transaction. I've also seen cases where
an exception is tolerated within a database transaction without ending
the transaction or prohibiting further queries (e.g. an insert fails,
and you can try an update, all in the same transaction).
It may be that the framework is not handling the PostgreSQL approach of
"aborting" a database transaction without rolling it back. This may
require a fix in JBoss.
-Kevin
>>> Dave Cramer <pg@fastcrypt.com> 07/19/05 8:59 PM >>>
Somewhere before the query that threw the exception an error occured.
Fix that and this exception will go away.
. . .
>>> 2005-07-19 12:14:54,506 DEBUG
>>> [org.jboss.ejb.plugins.cmp.jdbc.JDBCEJBQLQuery.UserDeviceEntityBean#
>>> findAllByUser]
>>> Executing SQL: SELECT t0_o.userId, t0_o.deviceId FROM
>>> rcp_user_device
>>> t0_o WHERE (t0_o.userId = ?)
>>> 2005-07-19 12:14:54,509 ERROR
>>> [org.jboss.ejb.plugins.cmp.jdbc.JDBCEJBQLQuery.UserDeviceEntityBean#
>>> findAllByUser]
>>> Find failed
>>> org.postgresql.util.PSQLException: ERROR: current transaction is
>>> aborted, commands ignored until end of transaction block
