Solved

MessageDriven bean, pause when resource is not available

Posted on 2004-09-14
10
356 Views
Last Modified: 2012-06-27
I'm new to message driven beans but I'd like to use one.

The purpose of the bean is to do sg in the database.

However, the db will not be always available. In such case, I'd like to  have it to wait until it becomes available again.

I know that I could check if it is available and thread.sleep if not but I wonder if there is a better way to do it.
0
Comment
Question by:zsoltvincze
  • 3
  • 3
  • 2
  • +1
10 Comments
 
LVL 35

Expert Comment

by:TimYates
Comment Utility
I can't think of a better way... :-(
0
 
LVL 35

Expert Comment

by:TimYates
Comment Utility
Instead of Thread.sleep (which will freeze your entire MDB), why not start a TimerTask to perform the function when the db is awake again?
0
 
LVL 35

Expert Comment

by:TimYates
Comment Utility
> why not start a TimerTask

why not start a repeating TimerTask

Task
1.  Is DB awake?
2.  Yes, perform action on database and close timer
3.  No, end this loop, and repeat to 1 in a set number of seconds
0
 
LVL 86

Expert Comment

by:CEHJ
Comment Utility
Isn't it more appropriate for what's sending the bean the message to do the waiting?
0
 

Author Comment

by:zsoltvincze
Comment Utility
I cannot see why a Timer is better then the Thread.sleep. Neither of them will freeze anything. I'm running it under jboss by the way. Would the behaviour change on a diff. app server?

Here is my simple test:

MessageBean1 : Sleeps for 2 minutes in onMessage
MessageBean2 : Sleeps for 5 seconds in onMessage
Queue 1 for Bean1
Queue 2 for bean2

Both writes to the console so I can see what is happening.

From the client: Send 30 messages to Queue1.
While it is happening, I can see that the server is picking up the messages and the Sleep function takes control. The server picks up 15 messages before proceeding with the next ones. (as per server setting)

At this stage, nothing is really happening, 15 messages are being executed and they are all asleep.

Now, I send a bunch of messages to Queue2 and the server picks them all up and their onMessage runs.

Some time after, Bean1 beans wake up and the server executes the next based on the queued messages.

So to me it looks ok but I still have two questions:
1. (as the original) Isn't there a built in functionality that would turn off the processing of the messages, with other words they would automatically get queued but not processed.

2. If the answer for Q1 is NO, would my little test work differnently on a diff app server?
0
Better Security Awareness With Threat Intelligence

See how one of the leading financial services organizations uses Recorded Future as part of a holistic threat intelligence program to promote security awareness and proactively and efficiently identify threats.

 

Author Comment

by:zsoltvincze
Comment Utility
re:CEHJ's comment
The client(s) have no idea what the bean is supposed to do and they have no access to the db. Plus they do not care, they just want to send the message.
0
 
LVL 86

Expert Comment

by:CEHJ
Comment Utility
ok ;-)
0
 
LVL 11

Expert Comment

by:cjjclifford
Comment Utility
I would take care with using a TimerTask, and returning from onMessage(), as this will remove the object from the queue, especially if you are using AUTOACK.

What's the problem with waiting inside onMessage() if resources are not available - once all deployed MDBs are waiting as such, the queue will take the backlog of requests from clients, and if configured, the clients will eventually wait on submission, etc. Surely the MDB's purpose is to process the incoming message and perform the DB related task, nothing more, so causing this to block waiting for resources is not a problem... if there is more operations than that present in the MDB, which can proceed without the DB operations, then this could be split further, with one MDB handling these operations, then placing the message onto another queue, for the DB-only MDB for processing...

Cheers,
C
0
 

Author Comment

by:zsoltvincze
Comment Utility
All right, that confirms that what I was thinking, such us coding the wait, was right.

I'm still not sure however what the diff is between sleep and timer.

In terms of memeory it seems to be about the same.

What I do not get is the "and if configured, the clients will eventually wait on submission, etc." line.

Does it refer to some "queue size" server parameter? Can you explain this please?

Bottom line is: Clients mustn't wait and must be able to complete their transaction.
0
 
LVL 11

Accepted Solution

by:
cjjclifford earned 125 total points
Comment Utility
yup queue size, if JMS queue fills up, etc. pretty sure this can be configured (obviously there is a theoritical limit to the queue length, so there must be a way to config. it - I've never run into upper lengths though....)

If clients "must not wait", then how valid is it that the MDB wait before flushing to DB? Surely if client can't wait, then it is safer to raise an exception back to them that the DB couldn't be written to (if they finish, and DB not available, and MDB waits, and eventually DB work fails, the client will never know... if this is acceptable, then make queue lengths as long as possible (obviously, you'll want to use persistent queues, otherwise a re-start of the JMS provider will cause pending messages to disappear!)

One thing about a timer is Timer runs TimerTask on seperate threads, so once a TimerTask is scheduled, control is returned back to the calling code. If you are going to use this in the onMessage(), then every message will cause a TimerTask to be added to the timer - causing a possible hole if the application is restarted/bounced! (isn't starting a new thread in EJB land a no-no?) Doing a while( noDBConnection ) { Thread.sleep( 2000 ); } in the onMessage() will (eventually, once all deployed bean instances have entered onMessage()) wait, causing messages to backup in JMS (persisted), which will then get processed when DB connection is available (to be really sure about restarts etc, use manual message acknowledgement, and ACK only after successful writing to DB, otherwise the message that caused the Thread.sleep() will be lost if the application fails before its written....)
0

Featured Post

How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

Join & Write a Comment

Suggested Solutions

After being asked a question last year, I went into one of my moods where I did some research and code just for the fun and learning of it all.  Subsequently, from this journey, I put together this article on "Range Searching Using Visual Basic.NET …
Introduction This article is the last of three articles that explain why and how the Experts Exchange QA Team does test automation for our web site. This article covers our test design approach and then goes through a simple test case example, how …
Viewers learn how to read error messages and identify possible mistakes that could cause hours of frustration. Coding is as much about debugging your code as it is about writing it. Define Error Message: Line Numbers: Type of Error: Break Down…
Viewers will learn about the different types of variables in Java and how to declare them. Decide the type of variable desired: Put the keyword corresponding to the type of variable in front of the variable name: Use the equal sign to assign a v…

744 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

9 Experts available now in Live!

Get 1:1 Help Now