JMS中为数不多的重点就是消息的确认机制，下面分别介绍J2EE和Spring的MessageListenerContainer的确认机制
J2EE中JMS确认机制
在JMS规范中一共4种确认方式
AUTO_ACKNOWLEDGE当调用recieve方法成功后或MessageListener处理函数成功返回后进行确认
CLIENT_ACKNOWLEDGE客户端通过message的acknowledge方法手动确认
DUPS_OK_ACKNOWLEDGE延迟确认，在对重复接受同一消息不敏感时可以选用此确认模式，相比AUTO_ACKNOWLEDGE有性能提升
SESSION_TRANSACTED调用session的commit或rollback进行事务式确认
Spring中的确认机制
多数情况下会使用Spring集成相关JMS的操作，可以减少相关开发的复杂度，但是Spring的确认方式和默认的JMS确认方式有些许不同，根据官方API
AUTO_ACKNOWLEDGE(默认):这个模式依赖于具体的实现，DefaultMessageListenerContainer中是在调用listener方法之前确认，SimpleMessageListenerContainer是在listener返回后确认，但是即使listener抛出异常，是不会重发的。
DUPS_OK_ACKNOWLEDGE延迟确认,同样也不会对用户异常进行重发
CLIENT_ACKNOWLEDGE当listener抛出异常时会进行重发
基于事务的确认将sessionTransacted设置为true，会在listener抛出异常进行重发，同时这也是spring推荐使用的方式
可以看出Spring的AUTO_ACKNOWLEDGE方式并不会关心listener抛出的异常，这个和J2EE的在listener成功返回后确认有所区别。
SpringJMS相关实现
下面看下SpringJMS MessageListenerContainer的继承树
Object
|-JmsAccessor
|-JmsDestinationAccessor
|-AbstractJmsListeningContainer
|-AbstractMessageListenerContainer
|-AbstractPollingMessageListenerContainer
|-DefaultMessageListenerContainer
|-SimpleMessageListenerContainer
|-SimpleMessageListenerContainer
如上面介绍的DefaultMessageListenerContainer和SimpleMessageListenerContainer是两个不同的分支，
前者继承了AbstractPollingMessageListenerContainer，从名字可以看出这个是客户端polling来获得消息的，也就是使用recieve方法，所以在API中说是在listener方法执行前确认的
后者是直接封装了MessageListener进行调用，但是对用户代码进行了异常控制所以就算抛出异常也不会进行重发，这个也许是为了统一AUTO_ACKNOWLEDGE的行为吧。
总结
spring默认的JMS确认方式是无法保证在用户代码出现异常时进行重发的（如OOM的情况等），这样会导致消息的丢失，在某些场景这个是不可接受的，所以使用中需要注意选用适当的确认方式进行JMS开发