JMS Sessions, "transacted" and "auto-acknowledge"
What does JMS session exactly mean?
What does it mean that a JMS session can be or not "transacted"?
What does it mean that a JMS session can be or not with "auto-acknowledge"?
Answer
You could view a JMS Session as the link between a connection and a thread's work on that connection. A JMS Session is a 'single-threaded context', so each thread must use a different session. In contrast, a JMS connection can be shared between multiple threads. Also, one thread could own multiple sessions.
The send/receive operations on a Session are either acknowledged or transacted.
Imagine a consumer crash: usually you want to redeliver a message if the consumer said it hasn't processed a message yet. So an acknowledgment (ACK) can be send from consumer to Broker to tell the JMS Broker that the message has been processed. Not just received but also stored in the Database, or whatever work the consumer is doing. If the consumer is restarted after the crash it will receive all messages that have not yet been acknowledged.
There are different forms of ACKs: auto-acknowledge means that the API will call acknowledge() for you after you've returned from your callback. In the other cases, you will have to call acknowledge() yourself.
Transactions group send or receive operations on that session (all-or-nothing). So you do send/send/send and then commit and know all 3 msgs are made available to the consumer at the time of the commit, or none. Advantages of transacted delivery: highest guarantee of delivery and you can group operations - Disadvantage: latency and possibly performance.
One main purpose of the Session is to keep a transaction's state. If your session was created to be transacted (SESSION_TRANSACTED) it knows all the messages that you are planning to send within your transaction and if that transaction is committed or rolled-back.