Packaging Exceptions

Troubleshooting

Data Corruption After an Application Exception

I see inconsistencies between the values I get from a bean method and those stored in the database after an application exception has occurred.

Because the container doesn't automatically roll back a transaction when an application exception occurs, the responsibility is on the bean provider to ensure data consistency. If a bean method changes the attribute values for the instance and then throws an application exception, data inconsistencies will result if the current transaction is committed. When using container-managed transaction demarcation , the bean method must call the setRollbackOnly method of EJBContext if the bean state cannot be restored before the exception is thrown. When using bean-managed transaction demarcation, the bean method should roll back the transaction before throwing the exception in this situation.

Loss of Conversational State Data

I lose the session data stored for a client by a stateful session bean when an exception is thrown.

When a system exception occurs, the only way the container can guarantee that access to a corrupted bean instance is prevented is to destroy the instance that threw the exception. This doesn't matter for entity or stateless session beans because any instance can serve a client request transparently . However, only a single instance of a stateful session bean holds the conversational state for a particular client. If a system exception is thrown from a stateful session bean, that state data is permanently lost. The client of a stateful session bean must be able to create a new session and start over in the event of a system exception.