Question: What is a Session?
Answer: A Session refers to all the request that a single client makes to a server. A session is specific to the user and for each user a new session is created to track all the request from that user. Every user has a separate session and separate session variable is associated with that session. In case of web applications the default time-out value for session variable is 20 minutes, which can be changed as per the requirement.

Question: What is Session ID?
Answer: A session ID is an unique identification string usually a long, random and alpha-numeric string, that is transmitted between the client and the server. Session IDs are usually stored in the cookies, URLs (in case url rewriting) and hidden fields of Web pages. 

Question: What is Session Tracking?
Answer: HTTP is stateless protocol and it does not maintain the client state. But there exist a mechanism called “Session Tracking” which helps the servers to maintain the state to track the series of requests from the same user across some period of time. 

Question: What  are different types of Session Tracking?
Answer: Mechanism for Session Tracking are:
a) Cookies
b) URL rewriting
c) Hidden form fields
d) SSL Sessions

Question: What is HTTPSession Class?
HttpSession Class provides a way to identify a user across across multiple request. The servlet container uses HttpSession interface to create a session between an HTTP client and an HTTP server. The session lives only for a specified time period, across more than one connection or page request from the user. 

Question: Why do u use Session Tracking in HttpServlet?
Answer: In HttpServlet you can use Session Tracking to track the user state. Session is required if you are developing shopping cart application or in any e-commerce application.

Question: What are the advantage of Cookies over URL rewriting?
Answer: Sessions tracking using Cookies are more secure and fast. Session tracking using Cookies can also be used with other mechanism of Session Tracking like url rewriting.

Cookies are stored at client side so some clients may disable cookies so we may not sure that the cookies may work or not.

In url  rewriting requites large data transfer from and to the server. So, it leads to network traffic and access may be become slow.

Question: What is session hijacking?
If you application is not very secure then it is possible to get the access of system after acquiring or generating the authentication information. Session hijacking refers to the act of taking control of a user session after successfully obtaining or generating an authentication session ID. It involves an attacker using captured, brute forced or reverse-engineered session IDs to get a control of a legitimate user’s Web application session while that session is still in progress.

Question: What is Session Migration?
Answer: Session Migration is a mechanism of moving the session from one server to another in case of server failure. Session Migration can be implemented by:
a) Persisting the session into database
b) Storing the session in-memory on multiple servers.

Question: How to track a user session in Servlets?
Answer: The interface HttpSession can be used to track the session in the Servlet. Following code can be used to create session object in the Servlet: HttpSession session = req.getSession(true);

Question: How you can destroy the session in Servlet?
Answer: You can call invalidate() method on the session object to destroy the session. e.g. session.invalidate();

Java IMP

What is the difference between ResultSet and RowSet ? Reference URL:

A ResultSet maintains a connection to a database and because of that it can’t be serialized and also we cant pass the Resultset object from one class to other class across the network.

RowSet is a disconnected, serializable version of a JDBC ResultSet and also the RowSet extends the ResultSet interface so it has all the methods of ResultSet. The RowSet can be serialized because it doesn’t have a connection to any database and also it can be sent from one class to another across the network.

More on RowSet:

A RowSet can be * connected * or *disconnected*
A *disconnected* rowset gets a connection to a data source in order to fill itself with data or to propagate changes in data back to the data source, but most of the time it does not have a connection open. While it is disconnected, it does not need a JDBC driver or the full JDBC API, so its footprint is very small. Thus a rowset is an ideal format for sending data over a network to a thin client.
A connected RowSet is like a wrapper around the ResultSet.
A CachedRowSet class—a disconnected rowset that caches its data in memory; not suitable for very large data sets, but an ideal way to provide thin Java clients, such as a Personal Digital Assistant (PDA) or Network Computer (NC), with tabular data

A JDBCRowSet class—a connected rowset that serves mainly as a thin wrapper around a ResultSet object to make a JDBC driver look like a JavaBeans component

A WebRowSet class—a connected rowset that uses the HTTP protocol internally to talk to a Java servlet that provides data access; used to make it possible for thin web clients to retrieve and possibly update a set of rows

From the above answer it seems that RowSet is far better than ResultSet. Ofcourse it is correct but there are some situations where we need to use ResultSet only.

For example when we are querying the database using the ResultSet object, as it is connected to the database until the object is open and it does not contain all the data from your query. Since it has a connection to the database, when you run the next() method if the ResultSet needs more data it can go to the database and get it. The RowSet can’t do that since it isn’t connected to the database so it must load and hold all the data from your query as soon as you run the execute() method. If your query returns a lot or rows you could encounter very slow processing and out of memory errors. However, if the number of rows to be returned is a reasonable number then a RowSet can be used.

By javaguideadmin Posted in Struts2

What is use of serialVersionUID

Reference URL : During object serialization, the default Java serialization mechanism writes the metadata about the object, which includes the class name, field names and types, and superclass. This class definition is stored as a part of the serialized object. This stored metadata enables the deserialization process to reconstitute the objects and map the stream data into the class attributes with the appropriate type
Everytime an object is serialized the java serialization mechanism automatically computes a hash value. ObjectStreamClass’s computeSerialVersionUID() method passes the class name, sorted member names, modifiers, and interfaces to the secure hash algorithm (SHA), which returns a hash value.The serialVersionUID is also called suid.
So when the serilaize object is retrieved , the JVM first evaluates the suid of the serialized class and compares the suid value with the one of the object. If the suid values match then the object is said to be compatible with the class and hence it is de-serialized. If not InvalidClassException exception is thrown.

Changes to a serializable class can be compatible or incompatible. Following is the list of changes which are compatible:

  • Add fields
  • Change a field from static to non-static
  • Change a field from transient to non-transient
  • Add classes to the object tree

List of incompatible changes:

  • Delete fields
  • Change class hierarchy
  • Change non-static to static
  • Change non-transient to transient
  • Change type of a primitive field

So, if no suid is present , inspite of making compatible changes, jvm generates new suid thus resulting in an exception if prior release version object is used .
The only way to get rid of the exception is to recompile and deploy the application again.

If we explicitly metion the suid using the statement:

private final static long serialVersionUID = <integer value>

then if any of the metioned compatible changes are made the class need not to be recompiled. But for incompatible changes there is no other way than to compile again.

Reference URL : If you ever implemented Serializable interface, you must encounter this warning message

The serializable class xxx does not declare a static final serialVersionUID 
field of type long

So…what is serialVersionUID?

The serialVersionUID is used as a version control in a Serializable class. If you do not explicitly declare a serialVersionUID, JVM will did it for you automatically, based on various aspects of your Serializable class, as describe in the Java(TM) Object Serialization Specification.

SerialVersionUID Example

The above statement is a bit hard to understand at the beginning (as least i did), let start an example to understand how Serializable class use SerialVersionUID to implement version control.


A serializable class with a serialVersionUID of 1L.


public class Address implements Serializable{

	   private static final long serialVersionUID = 1L;

	   String street;
	   String country;

	   public void setStreet(String street){
		   this.street = street;

	   public void setCountry(String country){ = country;

	   public String getStreet(){
		   return this.street;

	   public String getCountry(){

	   public String toString() {
    	   return new StringBuffer(" Street : ")
    	   .append(" Country : ")


A simple class to write / serialize the Address object into a file – “c:\\address.ser”.


public class WriteObject{

	public static void main (String args[]) {

	   Address address = new Address();
	   address.setStreet("wall street");
	   address.setCountry("united state");


	        FileOutputStream fout = new FileOutputStream("c:\\address.ser");
		ObjectOutputStream oos = new ObjectOutputStream(fout);

	   }catch(Exception ex){


A simple class to read / deserialize the Address object from file – “c:\\address.ser”.


public class ReadObject{

   public static void main (String args[]) {

	   Address address;


		   FileInputStream fin = new FileInputStream("c:\\address.ser");
		   ObjectInputStream ois = new ObjectInputStream(fin);
		   address = (Address) ois.readObject();


	   }catch(Exception ex){


Let do some testing to demonstrate the use of serialVersionUID.

1. Same serialVersionUID

Same serialVersionUID , there are no problem during deserialization process

java WriteObject
java ReadObject
Street : wall street Country : united state

2. Different serialVersionUID

In, change the serialVersionUID to 2L (it was 1L), and compile it again.

java ReadObject Address; local class incompatible:
stream classdesc serialVersionUID = 1, local class serialVersionUID = 2
        at ReadObject.main(

The “InvalidClassException” will raise, because you write a serialization class with serialVersionUID “1L” but try to retrieve it back with updated serialization class, serialVersionUID “2L”.

The serialVersionUID have to match during the serialization and deserialization process.

Suppose you have a class which you serialized it and stored in persistence and later modified that class to add a new field. What will happen if you deserialize the object already serialized?
–     It depends on whether class has its own serialVersionUID or not. As we know from above question that if we don’t provide serialVersionUID in our code java compiler will generate it and normally it’s equal to hash code of object. by adding any new field there is chance that new serialVersionUID generated for that class version is not the same of already serialized object and in this case Java Serialization API will throw and this is the reason its recommended to have your own serialVersionUID in code and make sure to keep it same always for a single class.

What is serialVersionUID? What would happen if you don’t define this?
– SerialVersionUID is an ID which is stamped on object when it get serialized usually hashcode of object, you can use tool serialver to see serialVersionUID of a serialized object .  serialVersionUID is used for version control of object. you can specify serialVersionUID in your class file also.  Consequence of not specifying  serialVersionUID is that when you add or modify any field in class then already serialized class will not be able to recover because serialVersionUID generated for new class and for old serialized object will be different. Java serialization process relies on correct serialVersionUID for recovering state of serialized object and throws in case of serialVersionUID mismatch.

package com.serializable_expl;

public class NameStore implements Serializable

    private static final long serialVersionUID = 9024561712115377771L;

    private String firstName;
    private transient String middleName;
    private String lastName;

    public NameStore (String fName, String mName, String lName)
        this.firstName = fName;
        this.middleName = mName;
        this.lastName = lName;

    public String toString()
        StringBuffer sb = new StringBuffer(40);
        sb.append("First Name : ");
        sb.append("   Middle Name : ");
        sb.append("   Last Name : ");
        return sb.toString();


package com.serializable_expl;


public class TransientExample

    public static void main(String args[]) throws Exception 
        NameStore nameStore = new NameStore("Steve","Middle","Jobs");
        ObjectOutputStream o = 
                 new ObjectOutputStream(new FileOutputStream("nameStore"));
        // writing to object
        System.out.println("Serialization of Object is done..!");

        // reading from object
        ObjectInputStream in =
                   new ObjectInputStream(new FileInputStream("nameStore"));
        NameStore nameStore1 = (NameStore)in.readObject();

        System.out.println("DeSerialization of Object is done..!");

Output  :-

Serialization of Object is done..!
First Name : Steve   Middle Name : null   Last Name : Jobs
DeSerialization of Object is done..!

If you need more in detail Examples then refer below mention URL :  Reference URL