Thursday, April 5, 2012

Handling Duplicate Form Submissions in Struts - Using Token in Struts


Using Token in Struts



Introduction
Using the various token methods provided by the base Struts Action class allows us to easily avoid the problem of allowing double submissions of forms or simply refreshing the page after a post has been made. This source code for this application is the same source code of the Struts CRUD with just a few modifications.
Requirements
This application requires an application server that implements the Servlet 2.4 and JavaServer Pages 2.0 specifications. The examples should all work on Tomcat 5.x (Discussed in next section). Please do not e-mail about getting your application to run on a server other than Tomcat. The source code (and an Ant build file) is provided for all the lessons so you should be able to build a war from the source and run it on you application server of choice.
Using the Token methods
The methods we care about are:
  • saveToken(HttpServletRequest req)
  • isTokenValid(HttpServletRequest req)
  • resetToken(HttpServletRequest req)

The basic concept I like to follow for implementing tokens:
  1. Always provide a setupForInsertOrUpdate dispatch method or indvidual Action. You could also break it up into setupForInsert and setupForUpdate if you so desire. Regardless, make sure you always go through this Action method before you go to your form.
  2. In your setup method make sure to call "saveToken(request)." This puts a unique key into Session scope and will cause this token to be placed on your resulting JSP.
  3. In your Action's update/insert dispatch method or your Action's execute method, make sure to first check if "isTokenValid(request)." This compares the token in Session with the one submitted through the Request. If they match, the token is valid and it's ok to procede with the update/insert. If they do not match, the user is likely simply resubmitting a stale page so we return from our action immediately.
  4. We need to remember before we leave our update/insert method that we call "resetToken(request)" so that we place a new token into Session scope, otherwise the old token will remain and it will match the one on the form and will allow duplicate submisssions.
Example
The following code sections from the source you can download, demonstrates the above.

public ActionForward setUpForInsertOrUpdate(ActionMapping mapping,
ActionForm form, HttpServletRequest request, HttpServletResponse response)
throws Exception {
    logger.debug("setUpForInsertOrUpdate");
    saveToken(request);
    EmployeeForm employeeForm = (EmployeeForm)form;
    if (isUpdate(request, employeeForm)) {
        Integer id = Integer.valueOf(employeeForm.getEmployeeId());
        Employee employee = empService.getEmployee(id);
        BeanUtils.copyProperties(employeeForm, employee);
    }
    prep(request);
    return mapping.findForward(Constants.SUCCESS);
}


    public ActionForward insertOrUpdate(ActionMapping mapping,
    ActionForm form, HttpServletRequest request, HttpServletResponse response)
    throws Exception {
    logger.debug("insertOrUpdate");
    EmployeeForm employeeForm = (EmployeeForm)form;
    if ( !isTokenValid(request) ) {
        return mapping.findForward(Constants.INVALID_TOKEN);
    }
    if (validationSuccessful(request, employeeForm)) {
        Employee employee = new Employee();
        BeanUtils.copyProperties(employee, employeeForm);
        if (isUpdate(request, employeeForm)) {
            logger.debug("update");
            empService.updateEmployee(employee);
        } else {
            logger.debug("insert" );
            empService.insertEmployee(employee);
        }
        populateEmployees(request);
        resetToken(request);
        return mapping.findForward(Constants.SUCCESS);
    } else {
        prep(request);
        return mapping.findForward(Constants.FAILURE);
    }
}
Usage
After installing the app, either by deploying the war or building from the source yourself, run the application and click on the "Add Employee" link. After you add the employee you'll be brought to the list of employees and you should see the employee you entered. Now use your browser's back button to go back to the form. You should still see your data entered on the form. Hit submit and you'll see how the token helps. You can also test out the use of the token by 'refreshing' the page after you do an insert and you are brought to the employees screen. You'll probably get prompted to 'repost' - click yes.
Other ideas
There are other things you can also do besides just using the token that often help for preventing resubmits of data. You can mark form pages as non-cachable with a "no-cache, no-store" cache-control header. You can also make sure to do redirects after you submit instead of forwarding to a results page. 

Handling Multiple Submits


Handling Multiple Submits

Listing 2 was certainly an improvement, but we've still got a ways to go. A number of issues still could go wrong. What if the user pushes the back button and starts over? What if his browser has JavaScript disabled or the browser cannot handle the processing? We can still solve the problem, but instead of preventing multiple submits, we need to handle them on the back end, via the form-processing servlet.


In order to understand how to solve the multiple submit problem, we must first understand how servlets work with respect to sessions. As everyone knows, HTTP is inherently a stateless protocol. In order to handle state, we need some way for the browser to associate the current request with a larger block of requests. The servlet session provides us a solution to this problem. The HttpServlet methods doGet() and doPost() use two specific parameters: HttpServletRequest and HttpServletResponse. The servlet request parameter allows us to access what is commonly referred to as the servlet session. Servlet sessions have mechanisms for accessing and storing state information.
What exactly is a servlet session? A servlet session is a number of things, including:
  • A set of state managed by the web server and represented by a specific identifier shared by all requests for a given client.
  • A place to store state data, defined, at least for HttpServlets, via the HttpSession interface.
Before we look at how to solve our problem with a server-side solution, we need to understand the servlet session lifecycle. As with EJBs and other server side entities, servlet sessions go through a defined set of states during their lifetime. The figure below shows the lifecycle of a servlet session. Servlets move through three distinct states: does not exist, new, and not new or in-use.
Figure 3: Servlet session lifecycle
servlet session lifecycle
  1. Initially, a servlet session does not exist. A session starts here or returns to this state for a number of reasons. Most likely, the user has never accessed the state before or the session was invalidated because the user left the site (timed out) or explicitly left (logged out).
  2. Sessions move from does not exist to new when the session is first created. The distinction between new and not new is important because of the fact the HTTP is stateless. According to the servlet specification, sessions cannot move to not new (from being a prospective session to an actual session) until the client returns the session to the server. Thus a session is new because the client does not yet know about it or the client decides not to join the session.
  3. When the session is returned to the server via a cookie or URL re-writing (more on that in a moment), then the session becomes in use or not new.
  4. Continued use of the session, via its various get and set methods, result in the session remaining in use.
  5. Transitions 5 and 6 happen when a session times out due to inactivity or a session is explictly invalidated. Application servers handle timeouts in a variety of ways. BEA WebLogic Server allows the application deployer the ability to set the session timeout via a special deployment descriptor (weblogic.xml) packaged with the web application.
NOTE: Careful use of getSession(true)
At first glance it appears that we should always use getSession(true). However, you should be careful in that a denial-of-service attack can be allowed by always creating new sessions on demand. An unscrupulous user could discover your site was creating sessions and flood it with new session requests. By using getSession(false) and then redirecting to a login page when a session is not detected, you can protect against such an attack.
In addition, there are many other interesting methods on HttpSession objects, such as isNew(), getAttribute(), setAttribute(), etc. The interested reader is pointed to the servlet specification for an exhaustive review.
Now that we understand the lifecycle of a session, how do we go about obtaining a session and using it to our advantage? The HttpServletRequest interface provides two methods for working with sessions:
  • public HttpSession getSession() always returns either a new session or an existing session.
    getSession() returns an existing session if a valid session ID was somehow provided (perhaps via a cookie). It returns a new session in several cases: the client's initial session (no session ID provided), a timed-out session (session ID provided), an invalid session (session ID provided), or an explictly invalidated session (session ID provided).
  • public HttpSession getSession(boolean) may return a new session, an existing session, or null.
    getSession(true) returns an existing session if possible. Otherwise it creates a new session. getSession(false) returns an existing session if possible and otherwise returns null.
We have still only solved half of the problem at hand. We'd like to be able to skip over the "session new" state and move to the "session in use" state automatically. We can achieve this by redirecting the browser to the handling servlet automatically. Listing 3 combines servlet session logic with the ability to redirect clients with valid sessions to the handling servlet.
Listing 3: RedirectServlet.java
01: package multiplesubmits;
02:
03: import java.io.*;
04: import java.util.Date;
05: import javax.servlet.*;
06: import javax.servlet.http.*;
07:
08: public class RedirectServlet extends HttpServlet{
09:  public void doGet (HttpServletRequest req, HttpServletResponse res)
10:   throws ServletException, IOException {
11:   HttpSession session = req.getSession(false);
12:   System.out.println("");
13:   System.out.println("-------------------------------------");
14:   System.out.println("SessionServlet::doGet");
15:   System.out.println("Session requested ID in Request:" +
16:   req.getRequestedSessionId());
17:   if ( null == req.getRequestedSessionId() ) {
18:    System.out.println("No session ID, first call,
        creating new session and forwarding");
19:    session = req.getSession(true);
20:    System.out.println("Generated session ID  in Request: " +
21:     session.getId());
22:    String encodedURL = res.encodeURL("/RedirectServlet");
23:    System.out.println("res.encodeURL(\"/RedirectServlet\");="
        +encodedURL);
24:    res.sendRedirect(encodedURL);
25: //

26:    // RequestDispatcher rd = getServletContext().getRequestDispatcher(encodedURL);
27:    // rd.forward(req,res);

28: //
29:    return;
30:   }
31:   else {
32:    System.out.println("Session id = " +
     req.getRequestedSessionId() );
33:     System.out.println("No redirect required");
34:   }
35:
36:   HandleRequest(req,res);
37:   System.out.println("SessionServlet::doGet returning");
38:   System.out.println("------------------------------------");
39:   return;
40:  }
41:
42:  void HandleRequest(HttpServletRequest req, HttpServletResponse res)
43:  throws IOException {
44:   System.out.println("SessionServlet::HandleRequest  called");
45:   res.setContentType("text/html");
46:   PrintWriter out = res.getWriter();
47:   Date date = new Date();
48:   out.println("<html>");
49:   out.println("<head><title>Ticket Confirmation</title></head>");
50:   out.println("<body>");
51:   out.println("<h1>The Current Date And Time  Is:</h1><br>");
52:   out.println("<h3>" + date.toString()  + "</h3>");
53:   out.println("</body>");
54:   out.println("</html>");
55:   System.out.println("SessionServlet::HandleRequest returning");
56:   return;
57:  }
58: }
Just how does this solve our problem? Examining the code closely shows that on line 11 we try to obtain a session handle. On line 17 we identify that an active session exists by checking the session ID for null, or by checking for a valid session ID. Either method suffices. Lines 18-29 are executed if no session exists. We handle the multiple submit problem by first creating a session as shown on line 19, using URL encoding to add the new session ID as shown on line 22, and then redirecting our servlet to the newly encoded URL, as shown on line 24.
NOTE: forward Vs. sendRedirect
Lines 26 & 27, while commented out, are shown as an example of something not to do. On first glance, forward seems to be a better solution to our problem because it does not cause a round trip to the browser and back. However, forward comes at a price; the new session ID is not attached to the URL. Using forward would cause the servlet to be called over and over in a loop, ultimately killing the application server.
Readers unfamiliar with URL rewriting are directed to lines 15 and 23. An HttpServlet object has the ability to rewrite a URL. This process inserts a session ID into a URL. The underlying application server can then use the encoded URL to provide an existing session automatically to a servlet or JSP. Depending on the application server, you may need to enable URL rewriting for the above example to work!

Conclusion

In this article, we discussed several solutions to the multiple submit problem. Each solution has its positive and negative aspects. When solving problems, the various pros and cons of a solution must be clearly understood to assess the value of each tradeoff. Our final example had the benefit of solving the problem at hand at the cost of an extra client round trip. The JavaScript solution was the most elegant, but required client support to work. As with any problem, there are often a world of solutions, each one with its own trade-offs. By understanding the trade-offs of a given solution, we can make the most informed choice for a given problem.

Thursday, October 20, 2011

Web Service


Web Services platform elements :-

XML is used to tag the data.
SOAP is used to transfer the data.
WSDL is used for describing the services available.
UDDI is used for listing what services are available.

-------------------------------------------------------------------
How to create the Web services 


Server creation
  1. Create a project in Workspace
  2. Create a java class with method which can be exposed as a web service.
  3. Expose this java class as a web service
  4. select create web service 
  5. select test web services
  6. select finish button
after this 
Click on finish - > this will generate WSDL file for your web service under Web content -> wsdl folder.


web service client :-

1. copy the wsdl file in web-inf/wsdl folder 
2. Right click on wsdl file and select webservice for webservice client creation 
3. Below java file will creating 
        Hello.java HelloService.java HelloServiceInformation.java HelloServiceLocator.java HelloSoapBuindigStub.java


if u want to call web services in jsp page below is code 


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<%@page language="java" contentType="text/html; charset=ISO-8859-1"
    pageEncoding="ISO-8859-1"%>
    <%@page import="java.net.*,org.ibm.*" %>
<html>
<head>
<title>index</title>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<meta name="GENERATOR" content="Rational Application Developer">
</head>
<body>
<%

  HelloService service = new HelloServiceLocator();

    Hello req = service.getHello(new URL("http://localhost:9081/WebSerAppServer/services/Hello" ));
   
    out.println(req.getMessage(" I am in JSP "));

%>
</body>
</html>










Tuesday, July 19, 2011

12 Multi-Threading Questions & Answers for Java Developers

Most of the Core Java interview questions are derived from MultiThreading & Collections framework. This post is a collection of some good questions in multi-threading area which I came across and thought of taking a note for referring anytime in future.
  1. What is synchronization in respect to multi-threading?

    With respect to multi-threading, synchronization is the capability to control the access of multiple threads to shared resources. Without synchronization, it is possible for one thread to modify a shared variable while another thread is in the process of using or updating same shared variable. This usually leads to significant errors.
  2. Explain different way of using thread? 

    The thread could be implemented by using Runnable interface or by extending the Thread class. The Runnable is more advantageous, when you are going for multiple inheritance.
  3. What is the difference between Thread.start() & Thread.run() method? 

    Thread.start() method (native method) of Thread class actually does the job of running the Thread.run() method in a thread. If we directly call Thread.run() method it will executed in same thread, so does not solve the purpose of creating a new thread.
  4. Why do we need run() & start() method both. Can we achieve it with only run method? 

    We need run() & start() method both because JVM needs to create a separate thread which can not be differentiated from a normal method call. So this job is done by start method native implementation which has to be explicitly called.
    Another advantage of having these two methods is we can have any object run as a thread if it implements Runnable interface. This is to avoid Java’s multiple inheritance problems which will make it difficult to inherit another class with Thread.
  5. What is ThreadLocal class? How can it be used? 

    - A thread-local variable effectively provides a separate copy of its value for each thread that uses it.
    - ThreadLocal instances are typically private static fields in classes that wish to associate state with a thread

    - In case when multiple threads access a ThreadLocal instance, separate copy of Threadlocal variable is maintained for each thread.
    - Common use is seen in DAO pattern where the DAO class can be singleton but the Database connection can be maintained separately for each thread. (Per Thread Singleton)

    Good article on ThreadLocal: http://www-128.ibm.com/developerworks/java/library/j-threads3.html

    Good example : http://javaboutique.internet.com/tutorials/localdata/

    Multithreading in Swing: http://java.sun.com/developer/JDCTechTips/2003/tt1208.html

    Refer API Docs:http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ThreadLocal.html

  6. When InvalidMonitorStateException is thrown? Why? 

    This exception is thrown when you try to call wait()/notify()/notifyAll() any of these methods for an Object from a point in your program where u are NOT having a lock on that object.(i.e. u r not executing any synchronized block/method of that object and still trying to call wait()/notify()/notifyAll())

    wait(), notify() and notifyAll() all throw IllegalMonitorStateException. since This exception is a subclass of RuntimeException so we r not bound to catch it (although u may if u want to). and being a RuntimeException this exception is not mentioned in the signature of wait(), notify(), notifyAll() methods.
  7. What is the difference between sleep(), suspend() and wait() ? 

    Thread.sleep() sends the current thread into the "Not Runnable" state for some amount of time. The thread keeps the monitors it has aquired -- i.e. if the thread is currently in a synchronized block or method no other thread can enter this block or method. If another thread calls t.interrupt() it will wake up the sleeping thread. Note that sleep is a static method, which means that it always affects the current thread (the one that is executing the
    sleep method). A common mistake is to call t.sleep() where t is a different thread; even then, it is the current thread that will sleep, not the t thread.

    t.suspend() is deprecated. Using it is possible to halt a thread other than the current thread. A suspended thread keeps all its monitors and since this state is not interruptable it is deadlock prone.

    object.wait() sends the current thread into the "Not Runnable" state, like sleep(), but with a twist. Wait is called on a object, not a thread; we call this object the "lock object." Before lock.wait() is called, the current thread must synchronize on the lock object; wait() then releases this lock, and adds the thread to the "wait list" associated with the lock. Later, another thread can synchronize on the same lock object and call lock.notify(). This wakes up the original,
    waiting thread. Basically, wait()/notify() is like sleep()/interrupt(), only the active thread does not need a direct pointer to the sleeping thread, but only to the shared lock object.
  8. What happens when I make a static method as synchronized?

    Synchronized static methods have a lock on the class "Class", so when a thread enters a synchronized static method, the class itself gets locked by the thread monitor and no other thread can enter any static synchronized methods on that class. This is unlike instance methods, as multiple threads can access "different synchronized instance methods" (not same method) at same time.
  9. Can a thread call a non-synchronized instance method of an Object when a synchronized method is being executed ?

    Yes, a Non synchronized method can always be called without any problem. In fact Java does not do any check for a non-synchronized method. The Lock object check is performed only for synchronized methods/blocks. In case the method is not declared synchronized Jave will call even if you are playing with shared data. So you have to be careful while doing such thing. The decision of declaring a method as synchronized has to be based on critical section access. If your method does not access a critical section (shared resource or data structure) it need not be declared synchronized.

    Below is the example which demonstrates this, The Common class has two methods
    synchronizedMethod1() and method1()
    MyThread class is calling both the methods in separate threads,

    1. public class Common {  
    2.   
    3. public synchronized void synchronizedMethod1() {  
    4. System.out.println("synchronizedMethod1 called");  
    5. try {  
    6. Thread.sleep(1000);  
    7. catch (InterruptedException e) {  
    8. e.printStackTrace();  
    9. }  
    10. System.out.println("synchronizedMethod1 done");  
    11. }  
    12. public void method1() {  
    13. System.out.println("Method 1 called");  
    14. try {  
    15. Thread.sleep(1000);  
    16. catch (InterruptedException e) {  
    17. e.printStackTrace();  
    18. }  
    19. System.out.println("Method 1 done");  
    20. }  
    21. }  

    1. public class MyThread extends Thread {  
    2. private int id = 0;  
    3. private Common common;  
    4.   
    5. public MyThread(String name, int no, Common object) {  
    6. super(name);  
    7. common = object;  
    8. id = no;  
    9. }  
    10.   
    11. public void run() {  
    12. System.out.println("Running Thread" + this.getName());  
    13. try {  
    14. if (id == 0) {  
    15. common.synchronizedMethod1();  
    16. else {  
    17. common.method1();  
    18. }  
    19. catch (Exception e) {  
    20. e.printStackTrace();  
    21. }  
    22. }  
    23.   
    24. public static void main(String[] args) {  
    25. Common c = new Common();  
    26. MyThread t1 = new MyThread("MyThread-1"0, c);  
    27. MyThread t2 = new MyThread("MyThread-2"1, c);  
    28. t1.start();  
    29. t2.start();  
    30. }  
    31. }  

    Here is the output of the program

    1. Running ThreadMyThread-1  
    2. synchronizedMethod1 called  
    3. Running ThreadMyThread-2  
    4. Method 1 called  
    5. synchronizedMethod1 done  
    6. Method 1 done  

    This shows that method1() - is called even though the synchronizedMethod1() was in execution.
  10. Can two threads call two different synchronized instance methods of an Object?

    No. If a object has synchronized instance methods then the Object itself is used a lock object for controlling the synchronization. Therefore all other instance methods need to wait until previous method call is completed.

    See the below sample code which demonstrate it very clearly. The Class Common has 2 methods called synchronizedMethod1() and synchronizedMethod2() MyThread class is calling both the methods

    1. public class Common {  
    2. public synchronized void synchronizedMethod1() {  
    3. System.out.println("synchronizedMethod1 called");  
    4. try {  
    5. Thread.sleep(1000);  
    6. catch (InterruptedException e) {  
    7. e.printStackTrace();  
    8. }  
    9. System.out.println("synchronizedMethod1 done");  
    10. }  
    11.   
    12. public synchronized void synchronizedMethod2() {  
    13. System.out.println("synchronizedMethod2 called");  
    14. try {  
    15. Thread.sleep(1000);  
    16. catch (InterruptedException e) {  
    17. e.printStackTrace();  
    18. }  
    19. System.out.println("synchronizedMethod2 done");  
    20. }  
    21. }  
    1. public class MyThread extends Thread {  
    2. private int id = 0;  
    3. private Common common;  
    4.   
    5. public MyThread(String name, int no, Common object) {  
    6. super(name);  
    7. common = object;  
    8. id = no;  
    9. }  
    10.   
    11. public void run() {  
    12. System.out.println("Running Thread" + this.getName());  
    13. try {  
    14. if (id == 0) {  
    15. common.synchronizedMethod1();  
    16. else {  
    17. common.synchronizedMethod2();  
    18. }  
    19. catch (Exception e) {  
    20. e.printStackTrace();  
    21. }  
    22. }  
    23.   
    24. public static void main(String[] args) {  
    25. Common c = new Common();  
    26. MyThread t1 = new MyThread("MyThread-1"0, c);  
    27. MyThread t2 = new MyThread("MyThread-2"1, c);  
    28. t1.start();  
    29. t2.start();  
    30. }  
    31. }  
  11. What is a deadlock?
  12. Deadlock is a situation where two or more threads are blocked forever, waiting for each other. This may occur when two threads, each having a lock on one resource, attempt to acquire a lock on the other's resource. Each thread would wait indefinitely for the other to release the lock, unless one of the user processes is terminated. In terms of Java API, thread deadlock can occur in following conditions:
    • When two threads call Thread.join() on each other.
    • When two threads use nested synchronized blocks to lock two objects and the blocks lock the same objects in different order.

  13. What is Starvation? and What is a Livelock?
  14. Starvation and livelock are much less common a problem than deadlock, but are still problems that every designer of concurrent software is likely to encounter.

    LiveLock

    Livelock occurs when all threads are blocked, or are otherwise unable to proceed due to unavailability of required resources, and the non-existence of any unblocked thread to make those resources available. In terms of Java API, thread livelock can occur in following conditions:
    • When all the threads in a program execute Object.wait(0) on an object with zero parameter. The program is live-locked and cannot proceed until one or more threads call Object.notify() or Object.notifyAll() on the relevant objects. Because all the threads are blocked, neither call can be made.
    • When all the threads in a program are stuck in infinite loops.

    Starvation

    Starvation describes a situation where a thread is unable to gain regular access to shared resources and is unable to make progress. This happens when shared resources are made unavailable for long periods by "greedy" threads. For example, suppose an object provides a synchronized method that often takes a long time to return. If one thread invokes this method frequently, other threads that also need frequent synchronized access to the same object will often be blocked.

    Starvation occurs when one thread cannot access the CPU because one or more other threads are monopolizing the CPU.

    In Java, thread starvation can be caused by setting thread priorities inappropriately. A lower-priority thread can be starved by higher-priority threads if the higher-priority threads do not yield control of the CPU from time to time.
This is not an exhaustive list of questions and I am sure I have missed many important questions from Multi-threading area. Can you think of a question which should be included in this list? Please feel free to share any question/suggestion in the comments section.