Container or bean provider cleans up resources when system exception occurs?

[Himai Minh]

Quote A says the container will clean up when a system exception occurs:

The bean provider can rely on the container to perform the following tasks when catching a non-application exception:
....
This means that unless the bean is a Singleton, the bean provider does not have to perform any cleanup... It is the container
that is responsible for the cleanup.
JSR 318 p.383.

Quote B says the bean provider/application should do the cleanup when a system exception occurs:

PreDestroy lifecycle callback interceptor method not being called:
...
A system exception thrown from the instance's method to the container.
... The application using the session bean should provide some clean up mechanism to periodically cleanup the unreleased
resources.
JSR 318 p.97

So, are quote A and quote B conflicting each other?

[Frits Walraven]

So, are quote A and quote B conflicting each other?

Not really. The cleanup (on page 97) has nothing to do with the current transaction or the bean that is involved.

They give a nice example of the cleanup they are talking about.

The note on page 97:

For example, if a shopping cart component is implemented as a session bean, and the session bean stores the shopping cart content in a database, the application should provide a program that runs periodically and removes "abandoned" shopping carts from the database.

[Himai Minh]

Thanks for Frits' reply.
So, on p.318, the container cleans up by logging the exception, rollback the transaction and discarding the bean when the stateless/stateful bean's business , lifecycle callback methods/interceptors throw system exceptions.

On the other hand, on p.97, the bean provider (developer) has to do the cleanup work that the container cannot do, such as closing the database connection, restoring the data in database, which are related to the application itself.