Saturday 15 November 2014

How to make Spring beans thread-safe ?

Spring beans are singleton by default.
Singleton means bean identified by a particular bean id will have only one instance.

Consider the following code:
@Controller
public class MyServlet {

    @Autowired
    private HelloService service;

    @RequestMapping(value="/hello", method = RequestMethod.GET)
    public void sayHello(HttpServletRequest req, HttpServletResponse res) throws IOException {
        service.doStuff();
    }

}


public class HelloService {

    private int i = 1;

    public void doStuff() {
        System.out.println("Started " + i);
        i++;
        System.out.println(Thread.currentThread().getName() + " Done " + i);
    }
}
The output will be something like this:
32911580@qtp-28064776-0 - Started 1
7802158@qtp-28064776-2 - Started 2
32911580@qtp-28064776-0 - Done 3
7802158@qtp-28064776-2 - Done 3
This prove the "i" var is shared between multiple threads.
Now lets try to define the HelloService bean as prototype, like this
<bean id="helloService" class="my.package.HelloService" scope="prototype" />
In this case as well, the result is the same.
The only ways this can be solved is : move the declaration into doStuff() method, but it's not what we want - make the doStuff() method, but this means have locks
What I would like is have a new instance of HelloService on every call.
Since you have only one instance of MyServlet you will also have only one instance of HelloService.
One of the following spring scopes help: request A new instance for each HTTP request. session A new instance of the class for each new HttpSession created in a servlet container.
This will change the semantics of your code. If you declare the bean in the scope request your counter will always be 1.
So, to make bean thread-safe, make the bean definition scope as "request" or "session".

Wednesday 12 November 2014

How to create a Bootable Windows 7 USB Flash Drive

Instructions to create a Bootable Windows 7 USB Flash Drive 

rufus How to Create a Bootable Windows 7 USB Flash Drive
  • Step 1: Download rufus on your computerand run it .
  • Step 2: Plug in your USB flash drive into your computer .
  • Step 3: From Rufu’s settings, Choose NTFS as the file system.
  • Step 4: Check ” Quick format ” and ”Create extended label and icon files “
  • Step 5: Check ” Create a bootable disk using ” and click the drive icon beside it to select the windows 7 ISO file .
  • Step 6: Now click on start to create a bootable window 7 USB flash drive .
After a few minutes your Windows 7 bootable  USB flash drive will be  ready for installation. Reboot your PC and set the bootable flash drive as a first boot priority in the bios settings. Save the bios settings and reboot once again to continue with the windows 7 installation process .
 Note: You have to allow booting from USB devices in your BIOS settings in order to proceed further with the windows 7 installation .

For those who install using the bootable USB Flash Drive

For newer desktop computer or laptop with USB 3.0 Ports, be sure to plug it in USB 2.0 ports to avoid the error. 

The rest proceed to the next step

To fix the problem:


  • Browse the file f6flpy-x86 or f6flpy-x64 file included in DVD drivers

  • If the file is not in the DVD, download the file in Microsoft Website

  • extract the file, put it in usb and browse the file.

Additional Resources

  • f6flpy-x64  f6flpy-x86  Windows 7 download f6flpy-x86 sata drivers

Sunday 2 November 2014

Why should immutable class be declared as final?

We have read that to make a class immutable in Java, we should do the following,
  1. Do not provide any setters
  2. Mark all fields as private
  3. Make the class final
Now have you ever thought why is step 3 required? Why should I mark the class final?
Lets see with the help of example.
If you don't mark the class final, it might be possible for me to suddenly make your seemingly immutable class actually mutable. For example, consider this code:
public class Immutable {
     private final int value;

     public Immutable(int value) {
         this.value = value;
     }

     public int getValue() {
         return value;
     }
}
Now, suppose I do the following:
public class Mutable extends Immutable {
     private int realValue;

     public Mutable(int value) {
         super(value);

         realValue = value;
     }

     public int getValue() {
         return realValue;
     }
     public void setValue(int newValue) {
         realValue = newValue;
     }
}
Notice that in my Mutable subclass, I've overridden the behavior of getValue to read a new, mutable field declared in my subclass. As a result, your class, which initially looks immutable, really isn't immutable. I can pass this Mutable object wherever an Immutable object is expected, which could do Very Bad Things to code assuming the object is truly immutable. Marking the base class finalprevents this from happening.