Closing down an IBM MQ classes for JMS application
It is important for an IBM MQ classes for JMS application to close certain JMS objects explicitly before stopping. Finalizers might not be called, so do not rely on them to free resources. Do not allow an application to terminate with compressed trace active.
Garbage collection alone cannot release all IBM MQ classes for JMS and IBM MQ resources in a timely manner, especially if an application creates many short lived JMS objects at the session level or lower. It is therefore important for an application to close a Connection, Session, MessageConsumer, or MessageProducer object when it is no longer required.
If an application ends without closing a Connection, an implicit rollback occurs for all the connection's transacted sessions. To ensure any changes made by the application are committed, close the Connection explicitly before closing the application.
Do not use finalizers in an application to close JMS objects. Because finalizers might not be called, resources might not be freed. When a Connection is closed it closes all the Sessions that were created from it. Similarly, the MessageConsumers and MessageProducers created from a Session are closed when the Session is closed. However, consider closing Sessions, MessageConsumers, and MessageProducers explicitly to ensure resources are freed in a timely manner.
If trace compression is activated, System.Halt() shutdowns and abnormal, uncontrolled JVM terminations are likely to result in a corrupt trace file. Where possible, turn off the trace facility when you have collected the trace information we need. If we are tracing an application up to an abnormal end, use uncompressed trace output.
Note: To disconnect from a queue manager, a JMS application invokes the close() method on the connection object. Parent topic: Writing IBM MQ classes for JMS applications