How about this example: A daemon application that checks a table for new entries every 15 minutes then does some processing calling some methods from an EJB on any new entries. Would there ever be a reason to sleep() in the EJB itself rather than the calling application?
I have to agree that I can't see any reason why you would call sleep in an EJB either. Dale > -----Original Message----- > From: Richard S.Martin [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 25, 2002 12:22 PM > To: [EMAIL PROTECTED] > Subject: Fwd: Re: Thread.sleep() > > > I am really curious to know why you need to wait for a period of time. > > I have been racking my brains and the *only* reason I can > think of (At least, > the only reason that doesn't make me think "Cack! Redesign!") > is to prevent > timing attacks. > > i.e Imagine you have a logon system that does an account > search first and > then, if the account is found, loads an entity and does a > password check. A > hacker running through a list of common usernames and > attempting a logon > against each one could detect when an account exists because > the time taken > for the call to return is greater. To prevent this, you can > compute the > average time taken to load the entity and compare passwords. > When a logon for > a non-existent user is attempted you then sleep for that period before > returning. > > In this case, you dont want your delay to be taking processor > cycles from > other threads, so a Thread.currentThread().sleep() is appropriate. > > Rich > > On Thursday 25 April 2002 16:03 pm, you wrote: > > Right. Thanks Richard! But I have to do something in my > bean, wait for some > > time, and then do something else. The time spent waiting > should be exact. > > What in this case? > > > > "Richard S.Martin" wrote: > > > The spec explicitly says you cannot: stop, start, suspend > or resume. It > > > does *not* say you cannot sleep a Thread. If the spec > authors didn't want > > > you to sleep a thread they would have put it in the list, > therefore you > > > can. Simple. > > > > > > Having said that. I find it hard to think of any reasons > why you would > > > want to. The original poster was talking about using it > to emulate a long > > > method call; well sleep wont emulate that very well since > it will be > > > idle. If you are trying to emulate a long method call, > your delaying > > > method should be active as well. Otherwise your profiling > results will be > > > [screwed | skewed] because other threads running will get > more time. > > > > > > for(long end = System.currentTimeMillis() + DELAY; end > > > > System.currentTimeMillis();) > > > > > > The only exception to this is if you are trying to > emulate a remote call; > > > in this case you should write a stub for your remote > object and put the > > > busy delay in there. This way you are still emulating the > marshalling and > > > network overhead involved. > > > > > > Rich > > > > -- > > "Bad times have a scientific value. These are the > occasions a good learner > > would not miss" --Ralph Waldo Emerson > > > > > > ********************************************************* > > Disclaimer > > > > This message (including any attachments) contains > > confidential information intended for a specific > > individual and purpose, and is protected by law. > > If you are not the intended recipient, you should > > delete this message and are hereby notified that > > any disclosure, copying, or distribution of this > > message, or the taking of any action based on it, > > is strictly prohibited. > > > > ********************************************************* > > Visit us at http://www.mahindrabt.com > > > > > ============================================================== > ============= > > To unsubscribe, send email to [EMAIL PROTECTED] and > include in the body > > of the message "signoff EJB-INTEREST". For general help, > send email to > > [EMAIL PROTECTED] and include in the body of the message "help". > > ------------------------------------------------------- > > ============================================================== > ================ > This email and any files transmitted with it are confidential > and intended solely for the use of the individual or entity > to whom they are addressed. All information is the view of > the individual and not necessarily the company. If you are > not the intended recipient you are hereby notified that any > dissemination, distribution, or copying of this communication > and its attachments is strictly prohibited. If you have > received this email in error please notify: > [EMAIL PROTECTED] > > > ============================================================== > ================ > > ============================================================== > ============= > To unsubscribe, send email to [EMAIL PROTECTED] and > include in the body > of the message "signoff EJB-INTEREST". For general help, > send email to > [EMAIL PROTECTED] and include in the body of the message "help". > =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
