Description:
If a manual confirm activity is used after the flow of BusinessConnect palette Receive Request activity, the messages are not confirmed properly back to the JMS queue resulting in non-deletion of the message from the queue. If a JMS receiver activity is used in place of the BC Palette receiver activity, JMS messages are deleted correctly.
Symptoms:
The message on EMS does not receive confirmation back from the PP(BC palette receiver activity) thereby resulting in non-deletion of the messages from the EMS queue. These messages may be resent to the PP resulting in duplicate messages. 
Cause:
When "Auto Confirm" is unchecked in BC, it uses Client Acknowledgement mode (value 2). Also, the receiver behavior in BC is different than the BW Receiver. While the BW Receiver calls receive (timeout) in a loop, where as BC uses OnMessage() calls. When the flow limit is reached, the consumer is closed which is expected behavior and BW does the same thing. However, after the consumer is closed, BC closes the session as well. When the confirm activity is called (which internally calls session.acknowledge() API of EMS), the confirm activity fails with the exception, "javax.jms.IllegalStateException: Session is closed".

When FlowLimit for a BW engine using a generic JMS receiver has been reached, BW will close the consumer, recover the session (will not close, so all unacknowledged messages received by that session will be re-delivered),  create a new consumer and this new consumer will keep on receiving the pending message. In contrast, the BC palette closes the session (after BW closes the consumer when FlowLimit is reached) instead of recovering it.