Enthuware

For the answer option 3, Isn't that if the MDB throws a runtime exception use BMT, the container should not acknowledge the message, so the message would also be redilieved?

In case of BMT, the message delivery is not part of the transaction. So even in case of an exception, the message is not redelivered. This is as per section 5.4.12.

HTH,
Paul.

I think there are two correct answers, the answer "He should use container managed transactions with transaction attribute of REQUIRED." and:

"Nothing. This is guaranteed by the container."

because the default TransactionManagement type is Container Managed and the default TransactionAttribute is REQUIRED.

Specs:
13.3.4.1 footnote
REQUIRED is the default transaction attribute value for container managed transaction demarcation
13.3.1
Typically enterprise beans will be specified to have container-managed transaction demarcation. This is the default if no transaction management type is specified.

Regards,
Frits

fjwalraven wrote:I think there are two correct answers, the answer "He should use container managed transactions with transaction attribute of REQUIRED." and:

"Nothing. This is guaranteed by the container."

because the default TransactionManagement type is Container Managed and the default TransactionAttribute is REQUIRED.

Specs:
13.3.4.1 footnote
REQUIRED is the default transaction attribute value for container managed transaction demarcation
13.3.1
Typically enterprise beans will be specified to have container-managed transaction demarcation. This is the default if no transaction management type is specified.

Regards,
Frits

This is a good point. But if you make this option right it may lead to a conclusion that the developer needs to do nothing for the message delivery part even if the bean uses BMT, which is not right.

Actually, it is not very intuitive that the transaction type of the bean directly affects the message delivery and so a developer has to consciously decide something (i.e. use CMT with REQUIRED) to achieve the desired behavior. Had it been a given in the question that the bean uses default transaction type, then "do nothing" would make more sense.

So to avoid this ambiguity, I have now changed the option to "This is guaranteed by the container for all types of MDBs.", which is unambiguously wrong.

Hope that makes is better. thanks for the feedback!
Paul.

I have same concern in this question which I raised for question

enthuware.oce-ejbd.v6.2.578

This was started by Jofen as well

BMT MDB will be redelivered the messages in case of RunTimeException since there is no acknowledgement from the container in this case.

Though Specifications did not give any clear statement about redelivery in case of BMT MDB but going by the reason that re-delivery will
depend on whether acknowledgement is recieved or not.
so in case of RuntimeException in BMT when container will not recieve the any acknowledgement , it wil try to redeliver .
Option 1 should be marked as correct answer .

My experience with Weblogic Server is that if system exception is thrown from BMT MDB, then the message is not redelivered. I had to manually reinsert a message after catching exception:/ Any experiences with other app servers?

J

As per Section 5.4.18, if a message-driven bean uses bean-managed transaction demarcation and throws a RuntimeException, the container should not acknowledge the message. Therefore the message will be redelivered.

Is this true, regardless of TransactionAttribute - NOT_SUPPORTED or REQUIRED?

No, not for NOT_SUPPORTED. If the transaction attribute is NOT_SUPPORTED that means there is no transaction in the bean. The container will therefore acknowledge the message irrespective of what the bean does.

In this case may I advise to add this detail to question/explanation. Otherwise it is not accurate.