Paul Boyce

Greenhorn
+ Follow
since May 31, 2004
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Paul Boyce

Hey! I got it sorted!

Its a pretty simple solution as follows:

1) Make Message Bean run with Container managed transaction and "Requires Transaction". (This ensures each execution of onMessage() runs in its own transaction.) The important settings in the deployment descriptor are:

<transaction-type>Container</transaction-type>
<acknowledge-mode>Auto-acknowledge</acknowledge-mode>

<trans-attribute>Required</trans-attribute>

2) A message is automatically acknowledged when the onMessage() method returns. To fail a message (i.e. not acknowledge it and leave it on the queue) simply call setRollBackOnly() on the MessageDrivenContext.

sample code:

public void setMessageDrivenContext(MessageDrivenContext newContext)
throws EJBException {
this.ctx = newContext;
}


public void onMessage(Message msg) {


// Cast the message to the expected type of object
TextMessage message = (TextMessage) msg;

boolean returnToQueue = true;
if (returnToQueue)
{
// Send message back ionto the queue to get reprocessed.
System.out.println("Message not cancelled - sending back to queue...");
ctx.setRollbackOnly();
}
}




For example my ebj-jar.xml contains as follows:

<ejb-jar >

<enterprise-beans>

<message-driven >

<ejb-name>RTSCRequestManagerBean</ejb-name>

<ejb-class>com.rtel.mdb.RTSCRequestManagerBean</ejb-class>

<transaction-type>Container</transaction-type>
<acknowledge-mode>Auto-acknowledge</acknowledge-mode>

<message-driven-destination>
<destination-type>javax.jms.Queue</destination-type>
</message-driven-destination>

<resource-ref >
<res-ref-name>jms/QueueConnectionFactory</res-ref-name>
<res-type>javax.jms.QueueConnectionFactory</res-type>
<res-auth>Container</res-auth>
</resource-ref>

</message-driven>
</enterprise-beans>

<container-transaction >
<method >
<ejb-name>RTSCRequestManagerBean</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>

</ejb-jar>


cheers,
Paul
Hello!

Any ideas how I can not acknowledge a message from a message driven bean (MDB) so it returns to the queue to be delivered again later???

My intention is to use a queue to store messages, and if the message cannot be processed when it comes off the queue (there is business logic in theMDB that decides if the message has to wait), i want the message to remain on the queue, to be redelivered later.

As I understand, an MDB will auto-acknowledge a message when the onMessage() method completes. By the J2EE spec, I cant throw an exception from the MDB, so how do I not acknowledge a message so it stays on the queue?

By the way, I am using a queue on JBoss 3.2.3.

Many thanks for your help,
Paul
Thanks everyone for your input. Its been really helpful. And its nice to know theres a great bunch of guys out there to shere the knowledge and experience.

cheers, Paul
Thanks everyone for your input. Its been really helpful. And its nice to know theres a great bunch of guys out there to shere the knowledge and experience.

cheers, Paul
Hello!

I'm no expert on network communications, and am trying to decide whether to use RMI or EJB (Session Beans) for a project.

My issue is whether using EJB will better manage server resources in terms of network connections/threads. I understand that with RMI each client call will result in a *new thread*. Is this correct and likely to be a problem that would be solved by using EJBs?

Background:
-----------
Our basic architecture uses two machines, one providing the web tier, and one providing the business and data access tier, as follows:

WebServer/WebContainer(Tomcat) ---network calls---> "business services" hosted on separate server"

In the communication between the WebContainer and the Business Services, our option is to use RMI to talk to plain old java objects (POJO) or use EJB Stateless Session Beans.

At the minute we don't have a strong argument to add the complexity of a EJB Container, but we are considering the EJB option if it will avoid problems where the RMI creates a NEW thread for every client call (from the web server).

Can you give any advice or views on this?

Many thanks in advance,
Paul
20 years ago
Session Beans and Firestorm JDBC in CMT transaction harmony. Isnt the world great! Many thanks for your help Kyle!

Paul
Will Session Bean transactions work if i use JDBC or FireStorm insterad of entity beans. How will RollBacks work with CMT?

Background:
-----------
I am considering using EJB session beans to provide the business layer, but do not want to use Entity Beans (in order to minimise the learning curve on a new project where the team hasnt used J2EE before). So I am considering using straight JDBC (or perhaps a product like Firestorm) to provide my data access layer. My concern is that I will end up with nested transactions which won't all rollback with CMT.

Will all be fine if I just open a new Connection at the start of a Stateless Sesion bean method and close the Connection at the end of the method?

Many thanks in advance,
Paul