[
https://jira.jboss.org/jira/browse/EJBTHREE-1558?page=com.atlassian.jira....
]
Jay Howell commented on EJBTHREE-1558:
--------------------------------------
The problem is not in the isDeliveryTransacted method, the problem is that the line that
is supposed to get the transaction attribute from the onmessage method always returns
null. it should return NOT_SUPPPORTED, which would cause the method to return false. The
method always returns true unless you specify BMT, because the annotation is busted for
some reason.
public boolean isDeliveryTransacted(Method method) throws NoSuchMethodException
{
TransactionManagementType mtype = TxUtil.getTransactionManagementType(container);
if (mtype == javax.ejb.TransactionManagementType.BEAN) return false;
TransactionAttribute attr =
(TransactionAttribute)container.resolveAnnotation(method, TransactionAttribute.class);
<-----This returns null always...
if (attr == null)
{
attr
=(TransactionAttribute)container.resolveAnnotation(TransactionAttribute.class);
}
TransactionAttributeType type = TransactionAttributeType.REQUIRED;
if (attr != null) type = attr.value();
return type == javax.ejb.TransactionAttributeType.REQUIRED;
}
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) ignored
on MDB onMessage
--------------------------------------------------------------------------------------
Key: EJBTHREE-1558
URL:
https://jira.jboss.org/jira/browse/EJBTHREE-1558
Project: EJB 3.0
Issue Type: Bug
Affects Versions: AS 4.2.2.GA
Reporter: Justin Bertram
Even when putting:
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
on the onMessage method of an MDB a transaction is still started. This can be verified
by using a simple MDB that sleeps for longer than the transaction timeout (300 seconds by
default). For example:
import javax.ejb.ActivationConfigProperty;
import javax.ejb.MessageDriven;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;
import javax.jms.Message;
import javax.jms.MessageListener;
import org.apache.log4j.Logger;
@MessageDriven(activationConfig = {
@ActivationConfigProperty(propertyName = "destinationType", propertyValue =
"javax.jms.Queue"),
@ActivationConfigProperty(propertyName = "destination", propertyValue =
"queue/A"),
@ActivationConfigProperty(propertyName = "maxSession", propertyValue =
"3") })
public class ExampleEJB3MDB implements MessageListener {
private static final Logger logger = Logger.getLogger(ExampleEJB3MDB.class);
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
public void onMessage(Message m) {
logger.info("message received, waiting for 10 mins...");
try {
Thread.sleep(600000); // 10 mins
} catch (InterruptedException e) {
}
logger.info("finished waiting");
}
}
When a message is sent to "queue/A" and the MDB picks it up it prints
"message received, waiting for 10 mins..." in the log. After 5 minutes (300
seconds) the message appears in the log again because the transaction has timed-out and
the message has been redelivered.
I believe the problem lies in org.jboss.ejb3.mdb.inflow.JBossMessageEndpointFactory in
the isDeliveryTransacted method. Here is that method [1]:
public boolean isDeliveryTransacted(Method method) throws NoSuchMethodException
{
TransactionManagementType mtype =
TxUtil.getTransactionManagementType(container);
if (mtype == javax.ejb.TransactionManagementType.BEAN) return false;
TransactionAttribute attr =
(TransactionAttribute)container.resolveAnnotation(method, TransactionAttribute.class);
if (attr == null)
{
attr
=(TransactionAttribute)container.resolveAnnotation(TransactionAttribute.class);
}
TransactionAttributeType type = TransactionAttributeType.REQUIRED;
if (attr != null) type = attr.value();
return type == javax.ejb.TransactionAttributeType.REQUIRED;
}
It seems there should be an explicit check for TransactionAttributeType.NOT_SUPPORTED.
If the MDB uses @TransactionManagement(TransactionManagementType.BEAN) then the redelivery
doesn't occur (since the code explicitly checks this attribute and returns false if it
is present).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira