• Post Reply Bookmark Topic Watch Topic
  • New Topic

jsp/servlet executes business method

 
Olexiy Prokhorenko
Ranch Hand
Posts: 97
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello guys,

I have few JSP/Servlets. Also, I have class with business methods, and my JSP/Servlets are invoking these business methods. These business methods could make calls to EJB, or access databases via JDBC, etc., etc., etc.

What is the easiest and proper way to make sure, that after invoking such business method our JSP/Servlet will wait for N seconds, and if method will not finish it's execution, so JSP/Servlet will just kill it?

How should I call my business methods from JSP/Servlets?
Also, the system will have pretty a lot of users, so I need to be sure that nothing will be corrupted/crashed because of the implementation of this task.

Thanks.
 
David O'Meara
Rancher
Posts: 13459
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I checked your cross post here, and what you may need are a couple of extra threads.

Have a 'processing thread' which does the work and has three states, working, finished and cancelled. When you start the thread, set it to 'working'. When it's done it should set itself to 'finished'. The second thread sleeps for the allocated time, looks at the state of the working thread then sets the state to 'cancelled' and stops it when it wakes up.

Then you just wait for the worker thread to become either finished or cancelled. There's some important synchronisation to do so that you can't cancel a thread which is finishing.

The trick is to organise it in a distributable way so that you can keep checking the state of the worker thread, you may have to spawn it all from a stateful EJB, but I'm no expert on threading in EJBs.

There may be a better way, or even a Pattern for this and I'd be happy to see it.

Dave
 
kri shan
Ranch Hand
Posts: 1481
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As per EJB spec EJB does not support threading code. Because appserver itself takes care threading.. Then how treading is poosible in EJB?
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Right, EJB tells you not to manage your own threads. But I've been doing it some in servlets ... I think it's allowed there, no?

Another general timeout technique is for the timeout thread to cause the main thread to throw an exception rather than just setting a cancelled flag. For example, if the main thread is waiting on a connection the second thread can sometimes close it and cause the first thread to fail.
 
Olexiy Prokhorenko
Ranch Hand
Posts: 97
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
from what I remember, J2EE prohibit using thread's in J2EE applications.
on practice, this could work on some containers, but could fail on others.
 
James Carman
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You could fire a new thread to call your business method. Then, call the join() method on the "business thread", but supply a timeout value. If your request times out (you'd have to come up with a way to let the "business thread" let you know that it's done, by setting some variable or something), then interrupt your "business thread" and return your response, indicating that the business method did not succeed. Now, this would require that your business method checks periodically to see if its executing thread has been interrupted (this is how you would "kill" it) and halt its execution, or at least check at the end so that it knows to rollback any changes it has made.
 
Senthil B Kumar
Ranch Hand
Posts: 160
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Put your business logic code in EJB's and make calls to utility classes to make db connection/transaction.

call these business code from your servlets. dont do it from your jsp cauz.. thatz not a gud pattern.

jsp's are meant only for presentation logic. servlets should just act as an middle layer between your actual business code and presentation.

the container will take care of the Transaction Management of the business process by default..

or you can use JTA to manage the transaction the way you wanted..
 
Senthil B Kumar
Ranch Hand
Posts: 160
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
check out the MVC Blueprint Pattern for info abt using jsp for presentation & ejb's for business
 
David O'Meara
Rancher
Posts: 13459
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
kolkata, PLEASE reduce the use of contractions in your posts.

cauz, thatz, gud, etc

They make your posts harder to understand and this defeats the purpose of you trying to help out.

thanks,
Dave.
 
subhit chauhan
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As per my understanding of your question, i think we dont need any type of threading. just use the proper exception handling mechanism.
When you are calling a method on your business layer whether its an EJB or some other java class use a proper exception handling. If something goes wrong whether system exception or the application exception, throw that back to your servlet. The execution of your business method will get over when it will throw back the exception object and you just need to handle it propertly in your servlet if you want to show the user what type of exception happened.
your main thread which is going to cal the business method going to wait till the it return back either exception or some other object or void and than only your next line of code will get executed.
 
David O'Meara
Rancher
Posts: 13459
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
but the problem is that the servlet should reply to the client after a specified period of time, whether the processing is finished or not. This is not possible with a blocking call.

Asd I said I'm no EJB expert, but we have inmplemented threads spawned by EJBs before If it's "safer" from a servlet, you could still perform the processing in an EJB but manage the threading in the servlet container.

Dave
 
James Carman
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The problem is (as you pointed out Dave) that they want to make a method call on some business object (POJO, EJB, JAX-RPC, whatever). Now, method calls in Java are synchronous (or blocking) of course. But, they want to be able to call the method and wait for a specified maximum amount of time for it to return. If that maximum amount of time expires and the method is not finished, then they want to be able to "kill" the method invocation.

The first part, waiting for a specified timout period of time is the easy part. You can use the join() or wait() method and check for some condition which indicates that the business method has finished after it returns. When using the wait() method, your business method runner thread would have to explicitly call the notify() method on some monitor object so that your calling thread would know when to "wake up." Using the join method alleviates this burden by just returning when the thread on which it is called finishes. If you want to use some sort of thread pool, then you'll have to go with the wait()/notify() mechanism, since your threads in your pool don't really finish when they're done with your business method invocation.

The tough part is making your business method invocations "killable." Since the Thread.stop() method is deprecated and "inherently unsafe", the only way for your business method to KNOW that it needs to stop its execution is for it to check periodically for some sort of flag that indicates that it has been killed. Of course, when it realizes that it has been "killed", it's gonna have to cleanup anything that it has already done. Now, you may not actually need your business method to stop dead in its tracks, but just rollback anything that it has done using a transaction at the very end. In that case, all you have to do is set a flag that indicates that you should rollback as opposed to commit.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!