Solved

MessageDriven bean, pause when resource is not available

Posted on 2004-09-14
10
392 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
[X]
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
10 Comments
 
LVL 35

Expert Comment

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

Expert Comment

by:TimYates
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?
0
 
LVL 35

Expert Comment

by:TimYates
ID: 12055428
> 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
Get 15 Days FREE Full-Featured Trial

Benefit from a mission critical IT monitoring with Monitis Premium or get it FREE for your entry level monitoring needs.
-Over 200,000 users
-More than 300,000 websites monitored
-Used in 197 countries
-Recommended by 98% of users

 
LVL 86

Expert Comment

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

Author Comment

by:zsoltvincze
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?
0
 

Author Comment

by:zsoltvincze
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.
0
 
LVL 86

Expert Comment

by:CEHJ
ID: 12057556
ok ;-)
0
 
LVL 11

Expert Comment

by:cjjclifford
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...

Cheers,
C
0
 

Author Comment

by:zsoltvincze
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.
0
 
LVL 11

Accepted Solution

by:
cjjclifford earned 125 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....)
0

Featured Post

[Webinar] How Hackers Steal Your Credentials

Do You Know How Hackers Steal Your Credentials? Join us and Skyport Systems to learn how hackers steal your credentials and why Active Directory must be secure to stop them. Thursday, July 13, 2017 10:00 A.M. PDT

Question has a verified solution.

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

This was posted to the Netbeans forum a Feb, 2010 and I also sent it to Verisign. Who didn't help much in my struggles to get my application signed. ------------------------- Start The idea here is to target your cell phones with the correct…
In this post we will learn different types of Android Layout and some basics of an Android App.
Viewers learn about the scanner class in this video and are introduced to receiving user input for their programs. Additionally, objects, conditional statements, and loops are used to help reinforce the concepts. Introduce Scanner class: Importing…
Viewers will learn about basic arrays, how to declare them, and how to use them. Introduction and definition: Declare an array and cover the syntax of declaring them: Initialize every index in the created array: Example/Features of a basic arr…

724 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