RE: [JBoss-user] Local/Global transaction with MDB

2004-01-05 Thread Adrian Brock
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-connectionfalse/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

RE: [JBoss-user] Local/Global transaction with MDB

2003-12-31 Thread Adrian Brock
On Wed, 2003-12-31 at 09:51, Adrian Brock wrote:
 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-connectionfalse/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

RE: [JBoss-user] Local/Global transaction with MDB

2003-12-31 Thread John Holmes
--- Adrian Brock [EMAIL PROTECTED] wrote:

 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.

Wrong! A connection factory could implement XA as well
as Non-XA interfaces (= a single connection factory
for all kind of stuff). It does not mean that XA
should be used if the cf implements an XA interface.
Therefore an explicit attribute is the proper way to
configure that.

__
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
http://search.yahoo.com/top2003


---
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=1278alloc_id=3371op=click
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user


RE: [JBoss-user] Local/Global transaction with MDB

2003-12-30 Thread Adrian Brock
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-connectionfalse/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 

RE: [JBoss-user] Local/Global transaction with MDB

2003-12-30 Thread thomas . cherel
Title: RE: [JBoss-user] Local/Global transaction with MDB





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.

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-connectionfalse/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

RE: [JBoss-user] Local/Global transaction with MDB

2003-12-29 Thread thomas . cherel
Title: RE: [JBoss-user] Local/Global transaction with MDB






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? 
 
 - 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-connectionfalse/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.

 - 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

 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).

 - 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.


 
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.


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_id=3371=click

___
JBoss-user mailing list
[EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user