How to handle EJBException in cases where execution should continue

Question

I have a question about how to handle EJBExceptions in some special cases.

General situation

In our application an EJB (3.0) DataAccessObjects(DAO) are responsible for all database access, these are used in other parts of the application.

Exceptions in the database layer are expected, for instance because of Optimistic Locking or Database constraint violations. The exceptions often thrown outside of the DOA class, because they occur on commit of the automatic JTA transaction. The calling class then receives this exception wrapped in an EJBException.

In most cases ignoring or logging and rethrowing the EJBException is best, as our JMS will trigger automatic retries for MessageDrivenBeans. In two cases, we don't want the exception to be propaged, as they have unwanted side effects.

Handling in JSF

In our JSF website we use the following pattern to display user friendly messages:

@ManagedBean
@ViewScoped
public class MyDataController {
   @EJB
    private MyDataDao myDataDao ;

    public void addData(){
        FacesMessage msg;
        try {
            Data data = new Data();
            // Data gets filled

            myDataDao.addData(data);
            msg = new FacesMessage(FacesMessage.SEVERITY_INFO, "Succes",
                    data.getName());
        }
        catch (EJBException e) {
            LOGGER.warn("Failed to add data"newCompanyName, e);
            if (ExceptionUtils.getRootCause(e) instanceof SQLIntegrityConstraintViolationException) {
                msg = new FacesMessage(FacesMessage.SEVERITY_FATAL, "Failed",
                     data.getName());
            }
            else {
               msg = new FacesMessage(FacesMessage.SEVERITY_FATAL,
                       "Failed to add data for unknown reason", data.getName());
            }
        }
    }
}       

Handling in Schedules tasks

In a related case, we call the database from a timed task (created using @Schedule). However this task is destroyed when (two consecutive?) exceptions occur while running it (at least in Weblogic). For us it is very important that this task keeps running even if exceptions during handling occur.

We have achieved this by catching and logging all EJBExceptions, as explained in this answer and in this answer. (Actually in our case we decided to catch all exceptions).

Problem

The above solutions mostly work as intended. However, we recently found that Errors are wrapped in an EJBException as well. For instance an OutOfMemoryError. In this case it caused the error to be swallowed, disabling the normal mechanism in Weblogic that would restart the application in case of an OutOfMemoryError.

Effectively this has downgraded Errors to Exceptions.

Question

The only solution I have is to check the recursively check the exception and its causes for instances of type Error, and if that is the case, rethrow the EJBException.

What is the correct way to handle the EJB exceptions in these situations?