• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1678
  • Last Modified:

Calling Tread.sleep() in session bean


Hi All,

i want to implement the retry logic inside one stateless session bean.
is it a good idea to call Thread.sleep() for making the current thread to wait before doing the retry?
is the Thread.sleep() will sleep the current execution thread?is there any side effect if i am make sleeping the thread which spaun by EJB container?
or any other way i can implement this?

All the inputs are welcome

regards
manoj velliyatt
0
manojvelliyatt
Asked:
manojvelliyatt
  • 4
  • 4
  • 3
  • +2
3 Solutions
 
zzynxSoftware engineerCommented:
>> is the Thread.sleep() will sleep the current execution thread?
sleep() "causes the currently executing thread to sleep (temporarily cease execution) for the specified number of milliseconds"
0
 
manojvelliyattAuthor Commented:
i am looking for usage inside the Stateless Session bean.
0
 
zzynxSoftware engineerCommented:
>> any other way i can implement this?
Using a Timer that triggers the retry functionality every x milliseconds

0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
petmagdyCommented:
it is prohibited to deal with threads in session or entity bean, if you want to implement scheduled logic, then u need EJB Timer bean which is available if the J2EE App Server is J2EE 1.4 complaint and the EJB is version 2.1 complaint, otherwise their is components like Quartz (open source) that help u to do soo, refer to this link:

http://www.opensymphony.com/quartz/
0
 
aozarovCommented:
>>  want to implement the retry logic inside one stateless session bean. is it a good idea to call Thread.sleep()
As petmagdy said you the EJB spec says that you should not interfer with the container threads directly (e.g by using sleep). (though the container will probably not notice that) .
EJB timer can trigger an SSB (one from the pool that is not currently in use) at specific time but I am not sure if this is what you are looking as you are expecting the synchrnous blocking call made by the client to come up with the response (after retry).
What is the operation you are taking from your SSB that you think will be available/successful after a short sleep?
0
 
limaidealCommented:
I think it is OK for you to use sleep() simply and straightforward in your case.
0
 
aozarovCommented:
>> I think it is OK for you to use sleep() simply and straightforward in your case.
To be honest I think so as well (even though its spec violation) but providing us more information can prove helpful as we may be able
to suggest alternatives.
0
 
aozarovCommented:
Or to comment on the necessity of that sleep ;-)
0
 
manojvelliyattAuthor Commented:
i am making some http call from my stateless session bean to do some thing.Some times the server can be busy.So i want to give a option of retry the same call after some time.i don't want to give up the call in first attempt because this session bean is part of a pipeline.So before that so many things happened before i got the data for processing.it is for giving the flexibility for the component; most of the times this retry situation will not comes into picture.

i have gone through the spec.it is not talking about making a sleep() call on the working thread.

                            The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt
                            to start, stop, suspend, or resume a thread, or to change a thread’s priority or name. The enterprise
                            bean must not attempt to manage thread groups.
0
 
zzynxSoftware engineerCommented:
So:
>> is it a good idea to call Thread.sleep() for making the current thread to wait before doing the retry?
Yes.
0
 
petmagdyCommented:
r u using the Thread this way:

Thread.currentThread().sleep(number);
0
 
manojvelliyattAuthor Commented:
Any differnce between calling Thread.currentThread().sleep(number); and Thread.sleep(number);

Both will work on curent execution thred right?
0
 
petmagdyCommented:
well try hread.currentThread().sleep(number) maybe it is different not sure
0
 
aozarovCommented:
> Both will work on curent execution thred right?
Right, there is no difference. sleep is a static method (and always applied on the current thread).
0
 
zzynxSoftware engineerCommented:
thanks
0

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

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.

  • 4
  • 4
  • 3
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now