0

This question follows directly from a previous question of mine in SO. I am still unable to grok the concept of JMS sessions being used as a transactional unit of work .

From the Java Message Service book :

The QueueConnection object is used to create a JMS Session object (specifically, a Queue Session), which is the working thread and transactional unit of work in JMS. Unlike JDBC, which requires a connection for each transactional unit of work, JMS uses a single connection and multiple Session objects. Typically, applications will create single JMS Connection on application startup and maintain a pool of Session objects for use whenever a message needs to be produced or consumed.

I am unable to understand the meaning of the phrase transactional unit of work. A plain and simple explanation with an example is what I am looking for here.

Community
  • 1
  • 1
Geek
  • 26,489
  • 43
  • 149
  • 227

3 Answers3

3

A series of messages of which all or none are processed/sent.

Peter Crotty
  • 301
  • 2
  • 9
3

A unit of work is something that must complete all or nothing. If it fails to complete it must be like it never happened.

In JTA parlance a unit of work consists of interactions with a transactional resource between a transaction.begin() call and a transaction.commit() call.

Lets say you define a unit of work that pulls a message of a source queue, inserts a record in a database, and puts the another message on a destination queue. In this scenario transaction aware resources are the two JMS queues and the database.

If a failure occurs after the database insert then a number of things must happen to achieve atomicity. The database commit must be rolled back so you don't have an orphaned record in the datasource and the message that was pulled off the source queue must be replaced.

The net out in this contrived scenario is that regardless of where a failure occurs in the unit of work the result is the exact state that you started in.

The key to remember about messaging systems is that a more global transaction can be composed of several smaller atomic transactional handoffs queue to queue.

Queue A -> Processing Agent -> Queue B --> Processing Agent --> Queue C

While in this scenario there isn't really a global transactional context(for instance rolling a failure in B->C all the way back to A) what you do have is garauntees that messages will either be delivered down the chain or remain in their source queues. This makes the system consistent at any instant. Exception states can be handled by creating error routes to achieve a more global state of consistency.

nsfyn55
  • 14,875
  • 8
  • 50
  • 77
  • "Exception states can be handled by created error routes to achieve a more global state of consistency." what you mean by this? can you please elaborate? – Geek Jun 27 '13 at 18:26
  • sure. I mean let your processing agent make a decision what queue to put stuff on. So your processing agent detects a problem, rather than failing and rolling back the transaction you may choose to instead route the message to a queue that handles error states. – nsfyn55 Jun 27 '13 at 20:36
0

Session may be created as transacted. For a transacted session on session.commit() all messages which consumers of this session have received are committed, that is received messages are removed from their destinations (queues or topics) and messages that all producers of this session have sent become visible to other clients. On rollback received messages are returned back to their destinations, sent messages removed from destination. All sent / received messages until commit / rollback are one unit of work.

Evgeniy Dorofeev
  • 133,369
  • 30
  • 199
  • 275