Java Interview Questions

2. Both the approaches have advantages & disadvantages

org.apache.struts.action.ActionServlet in the web.xml configuration file must defined as
ActionServlet provided by the struts Framework is a built-in servlet. ActionServlet nothing but a controller.It has the following inbuilt design patterns.
1 singleton designpatteren.

2.FrontController

3.ApplicationController

4.MVC

5.Data Transfer object/value object

6.Inversion of control/Dependency injection
ActionServlet take the multiple request but it creates single instance for that requests by using singleton design pattern.
Few servers likes weblogic violates single instance multiple threads principle of servlet programming.That means these servers that will create more than once object for a class in special situation. see hereTo avoid this type of situations & to follow servlet specifications, struts framework software developers have made built-in servlet called ActionServlet.
Note:

1. According to MVC principles, there should be only one servlet acting as controller and this servlet should have only one object.

2. Both the approaches have advantages & disadvantages

Hashtable

Hashtable is basically a datastructure to retain values of key-value pair.

• It didn’t allow null for both key and value. You will get NullPointerException if you add null value.
• It is synchronized. So it come with its cost. Only one thread can access in one time

1. Hashtable<Interger,String>; cityTable=new Hashtable<Interger,String>();
2. cityTable.put(1,”Lahore”);
3. cityTable.put(2,”Karachi”);
4. cityTable.put(3,null); // NullPointerException at runtime
5. System.out.println(cityTable.get(1));
6. System.out.println(cityTable.get(2));
7. System.out.println(cityTable.get(3));

HashMap

Like Hashtable it also accepts key value pair.

• It allows null for both key and value
• It is un-synchronized. So come up with better performance

1. HashMap<Interger,String>; prodcutTable=new HashMap<Interger,String>();
2. prodcutTable.put(1,”Keys”);
3. prodcutTable.put(2,null);

HashSet

HashSet does not allow duplicate values. It provides add method rather put method. You also use its contain method to check whether the object is already available in HashSet. HashSet can be used  where you want to maintain a unique list.

1. HashSet<String>; stateSet=new HashSet<String>();
2. stateSet.add(“CA”);
3. stateSet.add(“WI”);
4. stateSet.add(“NY”);
6. if(stateSet.contains(“PB”)) /* if CA,it will not add but shows following message */
7. System.out.println(Already found);
8. else
   
9. stateSet.add(“PB”);

Use hashSet if you just want to have a set of object, HashMap if you want some mappings(key-value pair), Use Hashtable in multi threaded enviroment as its synchronized (alternatively you can use a synchronizedMap as well)

For More Information on Collections Visit UTIL PACKAGE

you are reading my article because you want to learn how to write stored procedures. You are new to this, and you don’t know where to start. You are exactly where I was when I wanted to learn how to write stored procedures. The purpose of this article is to help the developer who doesn’t know where to start. I will give you a place to start, teach you techniques beyond the basic “hello world”, and walk you through examples. I learned how to write stored procedures alone, and have decided to let you use my experiences to your advantage. This article will consist of the following topics:

1. Input Variables

2. Input Variables with SELECT and UPDATE Statements

3. Exercise:  Pass Data to a SELECT Stored Procedure

4. Conclusion

5. Database script for SPFORBEGINNERS (the database referenced in this article)

At the end, I have also included a SQL script for creating the database used in my examples. It is a small database, and easily replicated.

What Are Stored Procedures?

Have you ever written SQL statements, like inserts, selects, and updates? Then you have already written most of a stored procedure. A stored procedure is an already written SQL statement that is saved in the database. If you find yourself using the same query over and over again, it would make sense to put it into a stored procedure. When you put this SQL statement in a stored procedure, you can then run the stored procedure from the database’s command environment.
An example is:

exec usp_displayallusers

The name of the stored procedure is “usp_displayallusers”, and “exec” tells SQL Server to execute the code in the stored procedure. (Note: “usp_” in front of the stored procedure name is used to designate this stored procedure as a user-created stored procedure.) The code inside the stored procedure can be something as simple as:

SELECT * FROM USERLIST

This “select” statement will return all data in the USERLIST table. You may think, skeptically, that stored procedures aren’t terribly useful. Just save the query and run it when you need to. Too easy, right?

Well, there is more to the story. Many queries get more complex than “select * from . . .”  Also, you may want to call the stored procedure from an application, such as an ASP page, Visual Basic application, or a Java servlet. With a stored procedure, you can store all the logic in the database, and use a simple command to call the stored procedure. Later, if you decide to use J2EE, you only need to change the application layer, which will be significantly easier. Much of the business logic will remain in the database.

Enough background—let’s write some stored procedures.

Getting Started with Stored Procedures

What do I need to get started? I have heard that question often. To begin writing stored procedures, the following are essential:

1. A database management system.

2. A database built inside the database management system (see the end of this article for a sample).

3. A text editor, such as Notepad or Query Analyzer.

Items 1 and 2 are absolutely essential. You can’t write stored procedures without a database. They would be useless. Sometimes, I write my procedures in Notepad (or another text editor), and copy them into the New Stored Procedure window in My SQL Server.

Next, you will have to decide what you want your stored procedure to do. It can be tempting to just dive right into the task at hand, but it is always prudent to sketch out some ideas first. Some considerations should be:

* Do you want to view data in the database (SELECT), insert new records (INSERT INTO), or do I want to change an existing record (UPDATE)?

* With which tables will you have to work? Does it make sense to create a VIEW first?

* How often will this procedure actually be used?

Once you have struggled with these questions (something of an exaggeration, I guess), you will be ready to start coding!

Note: Throughout this article, I will focus on stored procedures for My SQL Server. You can apply the same principles to other database management systems, but I will make clear references to working in a My SQL Server environment.

You May Consider this things also

Before creating a stored procedure, consider that:

* CREATE PROCEDURE statements cannot be combined with other SQL statements in a single batch.

* To create procedures, you must have CREATE PROCEDURE permission in the database and ALTER permission on the schema in which the procedure is being created. For CLR stored procedures, you must either own the assembly referenced in <method_specifier>, or have REFERENCES permission on that assembly.

* Stored procedures are schema-scoped objects, and their names must follow the rules for identifiers.

* You can create a stored procedure only in the current database.

When creating a stored procedure, you should specify:

* Any input parameters and output parameters to the calling procedure or batch.

* The programming statements that perform operations in the database, including calling other procedures.

* The status value returned to the calling procedure or batch to indicate success or failure (and the reason for failure).

* Any error handling statements needed to catch and handle potential errors.

Error handing functions such as ERROR_LINE and ERROR_PROCEDURE can be specified in the stored procedure.

So far, we’ve focused on the mechanics of serializing an object. We’ve assumed we have a serializable object and discussed, from the point of view of client code, how to serialize it. The next step is discussing how to make a class serializable.

Serialization is also called as Marker Interface

There are four basic things you must do when you are making a class serializable. They are:

1. Implement the Serializable interface.

2. Make sure that instance-level, locally defined state is serialized properly.

3. Make sure that superclass state is serialized properly.

4. Override equals( ) and hashCode( ).

Let’s look at each of these steps in more detail.
Implement the Serializable Interface

This is by far the easiest of the steps. The Serializable interface is an empty interface; it declares no methods at all. So implementing it amounts to adding “implements Serializable” to your class declaration.

Reasonable people may wonder about the utility of an empty interface. Rather than define an empty interface, and require class definitions to implement it, why not just simply make every object serializable? The main reason not to do this is that there are some classes that don’t have an obvious serialization. Consider, for example, an instance of File. An instance of File represents a file. Suppose, for example, it was created using the following line of code:

File file = new File(“c:\\New Floder\\Temp”);

It’s not at all clear what should be written out when this is serialized. The problem is that the file itself has a different lifecyle than the serialized data. The file might be edited, or deleted entirely, while the serialized information remains unchanged. Or the serialized information might be used to restart the application on another machine, where “C:\\New Floder\\Temp” is the name of an entirely different file.

Another example is provided by the Thread[4] class. A thread represents a flow of execution within a particular JVM. You would not only have to store the stack, and all the local variables, but also all the related locks and threads, and restart all the threads properly when the instance is deserialized.

TIP:   Things get worse when you consider platform dependencies. In general, any class that involves native code is not really a good candidate for serialization.

Make Sure That Instance-Level, Locally Defined State Is Serialized Properly

Class definitions contain variable declarations. The instance-level, locally defined variables (e.g., the nonstatic variables) are the ones that contain the state of a particular instance. For example, in our Money class, we declared one such field:

public class Money extends ValueObject {
private int _cents;
….
}

The serialization mechanism has a nice default behavior–if all the instance-level, locally defined variables have values that are either serializable objects or primitive datatypes, then the serialization mechanism will work without any further effort on our part. For example, our implementations of Account, such as Account_Impl, would present no problems for the default serialization mechanism:

public class Account_Impl extends UnicastRemoteObject implements Account {
private Money _balance;
…
}

While _balance doesn’t have a primitive type, it does refer to an instance of Money, which is a serializable class.

If, however, some of the fields don’t have primitive types, and don’t refer to serializable classes, more work may be necessary. Consider, for example, the implementation of ArrayList from the java.util package. An ArrayList really has only two pieces of state:

public class ArrayList extends AbstractList implements List, Cloneable, java.io.
Serializable {
private Object elementData[];
private int size;
…
}

But hidden in here is a huge problem: ArrayList is a generic container class whose state is stored as an array of objects. While arrays are first-class objects in Java, they aren’t serializable objects. This means that ArrayList can’t just implement the Serializable interface. It has to provide extra information to help the serialization mechanism handle its nonserializable fields. There are three basic solutions to this problem:

* Fields can be declared to be transient.

* The writeObject( )/readObject( ) methods can be implemented.

* serialPersistentFields can be declared.

You can find more information on serialization at 1 and 2