Making AQ usage transactional across session beans, using mosly JMS syntax

Question

I need to determine what I need to have in place in order for JMS/AQ messages to be "fully transactional".
I have a J2EE server application that will send JMS/AQ messages to a queue. I have a standalone application that reads messages from the queue, does some work, and then makes calls on multiple session beans (hosted in the original J2EE server application). Actually, it would likely be multiple calls to the same session bean method.
Once the standalone application reads a message from the queue, I need to ensure that if any action performed as a result of that message fails, that all the operations performed, including the removal of the message from the queue, are rolled back.
First of all, if I use an Oracle XA-compliant datasource, if one of the session bean calls fail, I can rollback the current transaction, but will this properly roll back any work that earlier session bean calls (made on the same transaction) did, even if they were successful (at the time)? Note that I have two JVMs, one running the J2EE application, and the other a standalone application reading from the queue.
Second, on committing or rolling back the message retrieval itself, I noticed from examples in the Oracle AQ Application Developer's Guide that if I create my QueueSessions with "AQDriverManager.createAQSession()", that I can pass a Connection object, and then later "commit" or "rollback", manually, perhaps if I got an EJBException from a session bean call.
However, I am trying to write my JMS/AQ code so that it uses as little of the direct AQ api as possible, staying with the standard JMS api. As a result, I'm using the JMS version of this, which is "QueueConnection.createQueueSession()". When I do this, however, it seems as if I lose control over the transaction.

Answer 1

Ok, I think I've answered some of this for myself, but I still have some concerns.
I see that the QueueSession object that I get back from "queueConnection.createQueueSession()" is likely going to actually be an instance of the "AQjmsSession" class, so I can cast to that, and then I can call "commit" or "rollback".
What is unclear from the javadoc description is what happens when "close()" is called on the session object. Does this do an implicit "commit()", perhaps unless "rollback()" has already been called?
I'm still a little uncertain about whether the scope of my transaction will be wide enough to protect everything that needs to be protected.
For instance, I assume that my transaction starts when my consumer (not in an application server) reads the message from the queue. At that point, my consumer does some "screen-scraping" work. When it's done, it will call a session bean on the application in the application server (separate JVM, in other words), which will create some EJB entity objects and also insert raw database rows. The session bean will then return, and then the original method which read a message from the queue will be completed.
What I need to know is what will happen if ANYTHING in that process fails, either in the external consumer, or in the session bean, or creating EJB entities? That is, will the entire transaction be rolled back, undoing the EJB entity creations AND the removal of the message from the message queue?
If this can possibly work, I'm assuming this would be utilizing an XA datasource, or a non-emulated data source (which I think means the same thing).