Want to win a PS4? Go Premium and enter to win our High-Tech Treats giveaway. Enter to Win


MessageDriven bean, pause when resource is not available

Posted on 2004-09-14
Medium Priority
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.
Question by:zsoltvincze
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 3
  • 3
  • 2
  • +1
LVL 35

Expert Comment

ID: 12055397
I can't think of a better way... :-(
LVL 35

Expert Comment

ID: 12055411
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?
LVL 35

Expert Comment

ID: 12055428
> why not start a TimerTask

why not start a repeating TimerTask

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
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

LVL 86

Expert Comment

ID: 12055461
Isn't it more appropriate for what's sending the bean the message to do the waiting?

Author Comment

ID: 12057517
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?

Author Comment

ID: 12057547
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.
LVL 86

Expert Comment

ID: 12057556
ok ;-)
LVL 11

Expert Comment

ID: 12062839
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...


Author Comment

ID: 12063971
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.
LVL 11

Accepted Solution

cjjclifford earned 375 total points
ID: 12064983
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....)

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Go is an acronym of golang, is a programming language developed Google in 2007. Go is a new language that is mostly in the C family, with significant input from Pascal/Modula/Oberon family. Hence Go arisen as low-level language with fast compilation…
Introduction This article is the second of three articles that explain why and how the Experts Exchange QA Team does test automation for our web site. This article covers the basic installation and configuration of the test automation tools used by…
This video teaches viewers about errors in exception handling.
How to fix incompatible JVM issue while installing Eclipse While installing Eclipse in windows, got one error like above and unable to proceed with the installation. This video describes how to successfully install Eclipse. How to solve incompa…
Suggested Courses

610 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