On Wed, 2003-12-31 at 03:07, [EMAIL PROTECTED] wrote:
> Adrian,
> 
> Thanks for the answer.
> 
> One little doubt that I'd like to clarify. In the Bean managed
> transaction case, you are saying "Bean managed is similar to
> NotSupported. Any transaction used to deliver the message is suspended
> allowing you to start your own user transaction that is disconnected
> from the original transaction."
> 
> I though that in this case, the incoming message was not read within a
> transaction, but just in JMS auto-acknoweldge mode, meaning that I
> soon as onMessage is called, the JMS incoming message has been
> acknowledge and it will never be delivered again (even if system crash
> or exception thrown from onMessage). The only case it could be
> re-delivered is if DUPS_OK_ACKNOWLEDGE is used in the ejb-jar.xml
> instead of AUTO_ACKNOWLEDGE.
> 
> Section 15.4.8 of EJB 2.0 spec: If bean managed transaction
> demarcation is used, the message receipt cannot be part of the
> bean-managed transaction, and, in this case, the receipt is
> acknowledged by the container. If bean managed transaction demarcation
> is used, the Bean Provider can indicate in the acknowedge-mode
> deployment descriptor element whether JMS AUTO_ACKNOWLEDGE semantics
> or DUPS_OK_ACKNOWLEDGE semantics should apply.
> 

Whether the message receipt and onMessage are transactional are
two independent processes/configurations.
Only with "Required" are the two linked in the same transaction
which requires an XAConnection to make it work consistently.

Regards,
Adrian

> Thomas
> 
> 
> -----Original Message-----
> From: Adrian Brock [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, December 30, 2003 10:58 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-user] Local/Global transaction with MDB
> 
> 
> On Mon, 2003-12-29 at 14:40, [EMAIL PROTECTED]
> wrote:
> > Nobody answer, so I can assume that it is all correct ? :-)
> > 
> > I do not want to trigger a lengthy debate that might have already
> been 
> > discussed previously. I am just looking for some pointers if
> something 
> > is not right in the way I think the MDB are working with
> transactions.
> > 
> > Thanks.
> > 
> > Thomas
> > 
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, December 23, 2003 1:30 AM
> > To: [EMAIL PROTECTED]
> > Subject: [JBoss-user] Local/Global transaction with MDB
> > 
> > 
> > 
> > I am trying to list the different possible transaction options and 
> > behavior for a Message Driven that is also sending JMS messages as 
> > part of the logic of its onMessage operation. This subject has
> already 
> > been touched through multiple post in the mailing list, but I did
> not 
> > find any consolidated version. Here is what  was able to determine
> so 
> > far. Please, feel free to comment, especially if something is not 
> > accurate.
> > 
> > Thanks.
> > 
> > Container-managed transaction
> > =======================
> >         - The trans-attribute of the onMessage operation can be set
> to 
> > Required or NotSupported. I am not sure to understand the difference
> > between the two since, in both cases, it seems that according
> > 
> >         to the EJB specification, the reading of incoming messages 
> > will be done within a transaction created by the container. In the 
> > case of Jboss, it seems that if NotSupported is used, the messages
> > 
> >         are read in a transaction but not in a global XA one (no 
> > messages can be sent as part of a global XA transaction from within 
> > the onMessage method). Can I expect that this behavior will be the 
> > same
> > 
> >         on all app servers?    
> >   
> 
> NotSupported means you isolate work done inside onMessage from the
> transaction used to deliver the message. If you do work in onMessage()
> or something it invokes, it won't be committed consistently with the
> original message delivery. (This might be what you want?)
> 
> >         - The connection factory of the input destination must be an
> > XA connection factory. This is not clearly stated by the spec, so I 
> > guess it is up to each app server. In the case of Jboss, I can use
> the
> > 
> >         <xa-connection>false</xa-connection> in the jboss.xml to 
> > specify that it is not. In this case, the JBoss container will do a 
> > "regular" commit on the JMS session. A global transaction is still 
> > created
> > 
> >         and JMS messages can be sent from within onMessage in this 
> > global transaction. When onMessage returns the global transaction is
> > committed and then the input message session is committed.
> 
> If you don't use an XAConnection, there is no two phase commit. The
> <xa-connection> flag was part of 3.0.x. In 3.2.x the type of
> connection is detected automatically based on the interface
> implemented by the connectionfactory.
> 
> > 
> >         - According to EJB spec, any JMS session open within a
> global 
> > transaction (open within a container managed transaction MDB) will
> be 
> > enlisted in the global transaction and the createXXXSession
> > 
> 
> You need to use a connectionfactory deployed by the resource adapter
> to make JMS work with JTA e.g. java:/JmsXA
> 
> >         parameters (boolean transacted, int acknowledgeMode) are 
> > ignored. It also means, I suppose, that the corresponding 
> > connectionFactory must be an XA connection factory. If a non-XA 
> > connection
> > 
> >         factory is used, the behavior is probably app server
> specific. 
> > In the case of Jboss, if a non-XA connection factory is used (not
> > JmsXA) the JMS session is not enlisted automatically and this is the
> > 
> >         responsibility of the onMessage code to do the commit (or
> > abort) on the JMS session (or to use auto-acknowledge JMS session).
> > 
> 
> Correct.
> 
> >         - In the case of an exception thrown by onMessage (it is not
> > supposed to happen, but just in case), any global transaction will
> be 
> > aborted. In the case the input message has been read in a regular
> JMS
> > 
> >         transaction (Jboss specific when input destination
> connection 
> > factory is not XA or when NotSupported is used for trans-attribute) 
> > then this regular JMS transaction is also aborted.
> > 
> 
> This is not defined by the spec (since the spec disallows throwing the
> exception). JBoss tries to handle the exception and rollback the
> transaction (XA or otherwise).
> 
> >  
> >         
> > Bean-managed transaction
> > ====================
> >         - This case is much simpler, a global transaction is never 
> > created by the container. The input JMS message is acknowledge
> before 
> > onMessage is called (according to the acknowledge-mode).
> > 
> >         - JMS messages sent from the onMessage code are following
> the 
> > regular JMS rules for transaction. Multiple messages can be sent 
> > within one global transaction if this transaction is explicitly
> > 
> >         created within the onMessage code (getUserTransaction) and 
> > provided that XA connection factories are used.
> > 
> 
> Bean managed is similar to NotSupported. Any transaction used to
> deliver the message is suspended allowing you to start your own user
> transaction that is disconnected from the original transaction.
> 
> Regards.
> Adrian
> 
> > Thomas
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IBM Linux Tutorials. Become an 
> > expert in LINUX or just sharpen your skills.  Sign up for IBM's Free
> > Linux Tutorials.  Learn everything from the bash shell to sys admin.
> > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> > 
> > _______________________________________________
> > JBoss-user mailing list
> > [EMAIL PROTECTED] 
> > https://lists.sourceforge.net/lists/listinfo/jboss-user
> -- 
> xxxxxxxxxxxxxxxxxxxxxxxx 
> Adrian Brock
> Director of Support
> Back Office
> JBoss Group, LLC 
> xxxxxxxxxxxxxxxxxxxxxxxx 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for
> IBM's Free Linux Tutorials.  Learn everything from the bash shell to
> sys admin. Click now!
> http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> 
> _______________________________________________
> JBoss-user mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-user
-- 
xxxxxxxxxxxxxxxxxxxxxxxx 
Adrian Brock
Director of Support
Back Office
JBoss Group, LLC 
xxxxxxxxxxxxxxxxxxxxxxxx 



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user

Reply via email to