Sunday 28 September 2008

Do you know? Enum in Switch statements

You can now use an enum type in a "switch" statement, Earlier the switch expression had to be an int type.
Sun's Javac says -"enum switch case label must be the unqualified name of an enumeration constant.
So let's understand this with a simple example:

package com.doyou.know;

public class EnumInSwitch {

public static enum
Month { Jan, Feb, March }

public void printMonth(Month month) {

switch(month) {
case(Month.Jan): //Wrong: can not use parenthesis
System.out.println("January month..");

case Month.Feb: //Wrong Too: Enum reference can not be qualified
System.out.println("February month..");

case March: //RIGHT : this is how you do it ...
System.out.println("March month...");
}
}

public static void main(String[] args) {
new EnumInSwitch().printMonth(Month.March);
}
}


To summarize:

• In case statement the enum must be used without brackets.
• In case only the unqualified enum name (Jan, Feb, March) must be used.

Friday 26 September 2008

Hibernate short summary part-I, page 3

Read the Article Page-I, Page-II
Client Application:
Let us write a client application to persist our USER object... it would involve the following steps ...
1) Load the hibernate configuration and initiate Hibernate session factory. Hibernate session factory is responsible for providing the sessions to do the database interaction stuff. You can assume for the time the session factory to be equivalent of the JDBC connection pool and each session equivalent of JDBc connection ....

2) Once the session factory is instantiated ...get an active session from it..

3) We would create a User object which we want to save in the database ...

4) initiate a hibernate transaction, save the object and commit... :) we are done ...
In summary ... you need to learn some basic APIs on hibernate session.

Let us write the program now ...

Client.java:
package client;

import org.hibernate.*;
import org.hibernate.cfg.Configuration;
import com.entities.User;

public class Client {
public static void main(String[] args) {

try{

Configuration conf = new Configuration().configure();
//by default configure tries to search
//hibernate.cfg.xml step-I is done

SessionFactory sessionFactory = conf.buildSessionFactory();

//step_II
Session session =sessionFactory.openSession();

//step_III
User user = new User();
user.setName("Test User");
user.setAge(24);
//note that we did not set userId because thats auto incriment
Transaction t = session.beginTransaction();
session.save(user);
//save inserts the row in the database...
t.commit();

System.out.println("User inserted with Id : " + user.getUserId());
session.close();

}
catch(Exception e){
e.printStackTrace();
}
}
}

As I already said for the above program to compile and run properly, two set of Jar files have to placed properly in the application's class-path. One is the set of Jar files that are available within the Hibernate Ditribution, which is normally the <HIBERNATE_INSTALLATION>\lib, where <HIBERNATE_INSTALLATION> refers to the installation of the Hibernate.

Following jar files from the Hibernate distribution have to be maintained in the class-path of the application,

cglib2.jar
commons-collections
commons-Logging
dom4j.jar
ehcache.jar
jdbc2.0-stdext
jta.jar
log4j.jar
odmg.jar
xalan.jar
xerces.jar
xml-apis.jar

The other set of the jar files are for the Jdbc Driver.

The above code establishes a Configuration object by calling new Configuration().configure() which scans the classpath for the presence of hibernate.cfg.xml file. It then creates an instance of SessionFactory object with the details populated from the Configuration File by calling Configuration.buildSessionFactory(). A new Session object is then created for persisting objects by calling SessionFactory.openSession().

A new Java object called 'User' is populated with some test values and the object is persisted into the Session object within a transactional context by calling Session.beginTransaction() which marks the beginning of the transaction. Remember that Session.save(object) only marks the object to be persisted. After a successful save operation and transaction is committed by calling Transaction.commit(), which means that the object will be synchronized with the database.

Hibernate short summary part-I, page 2

Read the Article page-I here

The next step is to define the hibernate framework configuration file. This is a xml file where we essentially define the 2 things

1) Database details : which database we are going to use, whats are the connection urls, username password and all the database related configurations.

2) We tell the hibernate which are the mapping files. framework uses these mapping files to identify the mapping between the classes and the underlying database tables.

Let us name this configuration file as hibernate.cfg.xml
-----------------------------------------------------------------------
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE hibernate-configuration PUBLIC
"-//Hibernate/Hibernate Configuration DTD//EN"
"http://hibernate.sourceforge.net/
hibernate-configuration-3.0.dtd">

<hibernate-configuration>
<session-factory>

<!-- Database connection settings -->
<property name="hibernate.dialect">
org.hibernate.dialect.OracleDialect
</property>
<property name="hibernate.connection.driver_class">
oracle.jdbc.OracleDriver
</property>
<property name="hibernate.connection.url">
jdbc:oracle:thin:@<host_name>:<port_number>:<database_name>
</property>
<property name="hibernate.connection.username">scott</property>
<property name="hibernate.connection.password">tiger</property>


<!-- Mapping files -->
<mapping resource="com/entities/User.hbm.xml"/>
</session-factory>
</hibernate-configuration>
------------------------------------------------------------------------------

The properties are explained below ...

hibernate.dialect :
This is the database specific attribute , hibernate identifies using this dialect how it will translate the queries... some of the example dialects are

Database SQL Dialect
SQL Server org.hibernate.dialect.SQLServerDialect
MySQL org.hibernate.dialect.MySQLDialect
Oracle org.hibernate.dialect.OracleDialect

hibernate.connection.driver_class : Identifies the JDBC driver class
hibernate.connection.url : Identifies the JDBC connection URL and the next 2 attributes are the database usernames and passwords.

< mapping-resource="com/entities/User.hbm.xml"/>> : tells the hibernate to load the mapping definition file, did you note the path given here is com/entities ?
because this where the mapping xml file is w.r.t to classpath context.

Now the next question is where we would keep the hibernate.cfg.xml ?
The essential answer is : it should be in the application classpath. you need to load this file while application initialization. so you should be aware of how to load this xml file.

So we are done with all the efforts. Lets summarize ..
we defined a table, a class , a mapping for class and table and hibernate configuration ...

The next step is to use the hibernate in our application to store and retrieve the Users. right?
We will write some sample program that would do these things ...

Thursday 25 September 2008

Hibernate short summary part-I

Hibernate addresses the one of the most important aspects of the Java applications, the data persistence. The data persistence facilities in the form of objects make it one of the most successful frameworks. I.e. as a Java programmer you see the underlying database tables as objects. Storing a row in the table for you is saving an object instance. The relation between the 2 tables for you is the references between the 2 objects, very simple indeed :). Guys believe me...if you are able to get these lines ...you have done the very first homework of learning the hibernate ... This is not a rocket science... have fun :)

This characteristic of hibernate is called the ORM [Object relational mapping] ORM is a piece of software/product for the representation and conversion of data between the database and the object-oriented programming language.

Another important feature which interests me most is that you need not worry about the database specific queries. e.g. the sql query to do some task X in oracle may be different from SQL Server, as a hibernate user I would not bother about it ... hibernate takes care of this for me .. how? We would come to it at appropriate time.

Things don't interest programmers unless they get their hands dirty with the codes and I would try to make things work for you in most simple way.

What you need to do next then?
1. Download and latest Hibernate. Hibernate is available for download at http://www.hibernate.org/
2. Create a simple java project in eclipse and Include the hibernate.jar file in the working directory. [don't know eclipse .. have coffee ..watch and learn here ]
3. Its good that you have some database installed.
4. Place your JDBC driver jar file for relevant to your database in the java project classpath.
5. You must know the connection parameters for your database. This could be the most frustrating thing for you to be able to run your hibernate application first time. Please note down your database connection URL, database name, port number, username, passwords etc. for more details read this

Next step is to create a simple USER table in the database as following ..

USER_ID <PK> int(10)
USER_NAME varchar(20)
USER_ PASSWORD varchar(10)
USER_ EMAIL varchar(20)

As I already said, we as a java programmer would view the underlying table as object ...so we would define a Class which would model the above table ... It should be straight forward isn't it ? This is gona be a simple java bean or Plain Old Java Objects... i.e. I would define the properties corresponding to the columns in the table.... how about the data types .. what should be the datatype for user_id ? :)

The only important thing is ...they should be compatible ... the fundamental rules are governed by java.sql.TYPES
here we go with the object definition ....

package com.entities

public class User {

private Long userId;

private String userName;
private String userPassword;
private String userEmail;

/** default constructor */
public User() {
}

public Long getUserId() {
return this.userId;
}

public void setUserId(Long id) {
this.userId = id;
}

public String getUserName() {
return this.userName;
}

public void setUserName(String userName) {
this.userName = userName;
}

public String getUserPassword() {
return this.userPassword;
}

public void setUserPassword(String userPassword) {
this.userPassword = userPassword;
}

public String getUserEmail() {
return this.userEmail;
}

public void setUserEmail(String userEmail) {
this.userEmail = userEmail;
}

}


Now, we have table ready..we have the class ready ...whats next ... ? I ask you a question ... how hibernate would determine ... which class refers which table .. which property of class maps to which column ? does this question makes sense ? of course it does ...

We are going to do next is to have a xml file ..which maps this stuff... and hibernate should be told to use this as the fundamental rules for mappig between the User class and USER table.... ok ?

<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
"-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">

<hibernate-mapping>
<class name="com.entities.User" table="user">
<id column="USER_ID" name="user_id" type="java.lang.Long">
<generator class="increment"/>
</id>

<property column="USER_NAME" name="userName"/>
<property column="USER_PASSWORD" name="userPassword"/>
<property column="USER_EMAIL" name="userEmail"/>
</class>
</hibernate-mapping>

let us name this file user.hbm.xml .... you can name it the way you like it ... but as a hibernate style ...we would name the mapping files with .hbm.xml suffix.... now the next question ....where you would keep this file ?


Genuine answer is ...keep it anywhere it has to be in classpath :) ... but we generally keep them along the corresponding java beans classes ...
so I would keep it in com.entities package, along with User.java


Hibernate mapping documents are straightforward. I will describe the major elements in the mapping file.
1. <hibernate-mapping> element
The root element of the Hibernate mapping document is the <hibernate-mapping> element. This element has several optional attributes.

2. <class> element
The <Class> element maps the object with corresponding entity [table] in the database. In simple words, the <class> element maps a table with the corresponding class. The <hibernate-mapping> element allows you to nest several persistent <class> mappings, as shown above. It is, however, good practice to map only a single persistent class in one mapping file and name it after the persistent superclass; for example, User.hbm.xml.

3. <id> element

The <id> element defines the mapping from that property to the primary key column. The <id> element represents the primary key column and its associated attribute in the domain object. Mapped classes must declare the primary key column of the database table. Most classes also will have a JavaBeans-style property holding the unique identifier of an instance.

4. <generator> element

The optional <generator> child element names a Java class used to generate unique identifiers for instances of the persistent class. This is like a unique id generator ... Some commonly used generators are:

1. Increment. Generates auto increment numbers of type long, short, or int that are unique.
2. Sequence. Uses a predefined sequence from oracle, DB2, PostgreSQL, SAP DB. The returned identifier is of type long, short, or int.
3. Assigned. Lets the application assign an identifier to the object before. This is the default strategy if no <generator> element is specified.
4. Foreign. Uses the identifier of another associated object.

Let us defer their deep understanding to the knowledge refinement phase :))

5. <property> element
The <property> element declares a mapping between property of the class and the underlying column.

Friday 19 September 2008

Convert java Date time between timezones.

The standard way to specify your target timezone is GMT +/- hours minutes
e.g. for BST i can say "GMT+1"

String mytimeZone = "GMT+1";
GregorianCalendar abroad = new GregorianCalendar(TimeZone.getTimeZone(mytimeZone));
System.out.println(abroad.getTime());

//Format the timezone specific date display..
DateFormat df1 = DateFormat.getDateTimeInstance(DateFormat.FULL, DateFormat.FULL);
df1.setTimeZone(TimeZone.getTimeZone(mytimeZone));
System.out.println(df1.format(abroad.getTime()));

//Format to GMT time
df1.setTimeZone(TimeZone.getTimeZone("GMT"));
System.out.println(df1.format(abroad.getTime()));

Thursday 7 August 2008

Hashcode and Equals

The hashcode method is inherited from the Object class. The signature of hashcode is
public int hashCode()

Generally a hashcode value will be the memory address of the object. You can demonstrate this to yourself quite easily with some trivial code such as.

public class ShowHash{
public static void main(String argv[]){
ShowHash sh = new ShowHash();
System.out.println(sh.hashCode());
}
}

When I compiled and ran this code I got an output of : 7474923
Which is a representation of the memory address of that class on that run of the program.

equals and hashCode

Every object has access to an equals method because it is inherited from the Object. However this default object does not always do anything useful as by default it simply compares the memory address of the object. To make the objects equal on your semantics, you need to override this method. Let us assume that If the String class did not implement its own version of the equals method comparing two Strings would compare the memory address rather than the character sequence. This is rarely what you would want, and for this reason the String class implements it's own version of the equals method that makes a character by character comparison.

Here is another of the points from the API documentation
If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result.

This principle is illustrated with the following code,

public class CompStrings{
public static void main(String argv[]){
String s1 = new String("Hello");
String s2 = new String("Hello");
System.out.println(s1.hashCode());
System.out.println(s2.hashCode());
Integer i1 = new Integer(10);
Integer i2 = new Integer(10);
System.out.println(i1.hashCode());
System.out.println(i2.hashCode());
}
}

This code will print out the same hashCode value for s1 and s2 and i1 and i2 on each run of the program. Objects that are equal according to the equals method must return the same hashCode value.
What if I ask otherwise . if objects have same hashcode are they equal ?

Not necessarily... inverse is not true. If two objects are not equal according to equals, they are not required to return different hashCode values.

"The summary is if two things are equal (according to equal()), they must have the same hashCode".

One more thing you must keep in mind is if you override anyone of these you should be overridding the other also.

The hashcode is of particular use with the hash based Collection classes like HashTable, HashSet, HashMap etc ... The nature of hash based collections is to store keys and values. The key is what you use to look up a value.

Illusteration : How Hashtable works.

  • Hash table implementations uses the hash code value to quickly get to the memory location where an object is stored as a key in a hash table. It is not necessary that hashCode() return a unique integer for an object. If two objects return the same hash code, equals() method is used to pick the one the hash table is looking for.

  • So, what does happen when two unequal objects return the same hash code? When Java goes to put objectA as a key and some other object as its value in a hash table using myHashtable.put(objectA, someValue), it first goes to the location indicated by objectA's hash code. If there is already an object there - may be because objectB has been stored there as a key previously, Java checks to see if objectA.equals(objectB). If yes, it replaces the value of key objectB with "soemValue". If no, Java puts objectA and someValue at a different location and creates a link from objectB to objectA. Next time Java needs to get the value of a key, say objectA, from the hash table, it goes to the location indicated by the hash code of the key object. Finding two objects there, it checks if the first object (objectB) equals the object in hand (objectA). If yes, it returns the value for the first object. If no, it goes down the link and checks if the second object (objectA) equals the object in hand (objectA). If yes, it returns the value of the second object. And so on.

  • When two unequal objects return the same hash code, it is called a "collision". It sounds dreadful and you would think some damage occurred. But no, nothing bad happened and you don't need any collision insurance. It just slows down the process of storing and retrieving those objects a bit. From JDK documentation: "Note that the hash table is open: in the case a "hash collision", a single bucket stores multiple entries, which must be searched sequentially." It will be nice if all objects returned unique hash codes. But in real life, it is not so. After all, a hash code can return a maximum of 2 billion or so combinations (maximum Java integer value) where as you can have infinite number of objects. Some of them will necessarily return the same hash code. Collisions are inevitable.

  • From JDK documentation: "An instance of HashMap has two parameters that affect its performance: initial capacity and load factor. The capacity is the number of buckets in the hash table, and the initial capacity is simply the capacity at the time the hash table is created. The load factor is a measure of how full the hash table is allowed to get before its capacity is automatically increased. When the number of entries in the hash table exceeds the product of the load factor and the current capacity, the capacity is roughly doubled by calling the rehash method."

    "As a general rule, the default load factor (.75) offers a good tradeoff between time and space costs. Higher values decrease the space overhead but increase the lookup cost (reflected in most of the operations of the HashMap class, including get and put). The expected number of entries in the map and its load factor should be taken into account when setting its initial capacity, so as to minimize the number of rehash operations. If the initial capacity is greater than the maximum number of entries divided by the load factor, no rehash operations will ever occur."
  • Thursday 17 July 2008

    Difference between a comparator and comparable

    If the List consists of String elements, it will be sorted into alphabetical order. If it consists of Date elements, it will be sorted into chronological order.

    How does this happen?

    String and Date both implement the Comparable interface. Comparable implementations provide a natural ordering for a class, which allows objects of that class to be sorted automatically

    If you try to sort a collection (yourCollection), the elements of which do not implement Comparable, Collections.sort(yourCollection) will throw a ClassCastException.

    Writing Your Own Comparable Types
    The Comparable interface consists of the following method.

    public interface Comparable {
    public int compareTo(T o);
    }

    The compareTo method compares the receiving object with the specified object and returns a negative integer, 0, or a positive integer depending on whether the receiving object is less than, equal to, or greater than the specified object.

    Now Any collection which maintains the natural ordering like TreeMap, TreeSet would automaticaly sort the entries on the logic of compareTo method. For others cases you would just call the Collection.sort(Collection col) on your collection whenever you want the entries to be sorted on natural order.

    Comparators

    What if you want to sort some objects in an order other than their natural ordering? Or what if you want to sort some objects that don't implement Comparable?
    e.g. naturally String sort the collection in dictionary order. What is you want the sorting to be just opposite of it ?
    you'll need to provide a Comparator in such cases — an object that encapsulates an ordering.

    Like the Comparable interface, the Comparator interface consists of a single method.

    public interface Comparator {
    int compare(T o1, T o2);
    }

    The implementation symantics are same to Comparable.

    import java.util.*;

    public class ReverseSort {
    static final Comparator REVERSE_ORDER =
    new Comparator() {
    public int compare(String e1, String e2) {
    return e2.compareTo(e1.hireDate()); //reverse comparison
    }
    };

    static final Collection names = ... ;

    public static void main(String[] args) {
    List e = new ArrayList(names);
    Collections.sort(e); //This would sort the names in Natural Order ... Dictionary order ...
    System.out.println(e);

    System.out.println("");
    System.out.println("Reverse Order ...");
    Collections.sort(e, REVERSE_ORDER);
    System.out.println(e);
    }
    }


    Wednesday 16 July 2008

    java 5 jconsole is VisulaVM in Java 6.0

    The jconsole has been upgraded with some exciting features in Java
    6.0.It is able to monitor applications running on JDK 1.4 and higher.
    It utilizes various available technologies like jvmstat, JMX, the
    Serviceability Agent (SA), and the Attach API to get the data and
    automatically uses the fastest and most lightweight technology to
    impose minimal overhead on monitored applications.

    Display local and remote Java applications.
    VisualVM automatically detects and lists locally and remotely running Java applications (jstatd
    must be running on the remote host). You can also define applications
    manually by JMX connection. This way you can easily see what Java
    applications are running on your system or check if a remote J2EE
    server process is alive.

    Display application configuration and runtime environment.
    For each application VisualVM shows basic runtime information: PID, main class, arguments passed to java process, JVM version, JDK home, JVM flags and arguments and system properties.

    Monitor application memory consumption and runtime behaviour.

    VisualVM monitors application heap and permanent generation memory,
    number of loaded classes and running threads. You can easily detect
    suspicious memory consumption and take an action - invoke garbage
    collection in the application or take a heap dump and browse the
    contents of application heap.

    Monitor application threads.

    All threads running in a Java process are displayed in a timeline. You
    can track thread activity and uncover inefficient patterns like blocked
    Event Dispatch Thread or unused worker threads.

    Profile application performance or analyze memory allocation.

    VisualVM has a built-in application profiler which can visualize where
    most of the time is being spent or which objects consume most of the
    memory by just one mouse click without any additional configuration.

    Take and display thread dumps.

    Taking and displaying a thread dump is as easy as clicking a mouse
    button. You don't need to deal with the command line at all to
    determine what's currently happening in the application. Moreover,
    simultaneous thread dumps of multiple applications can be taken at once
    to start uncovering distributed deadlocks.

    Take and browse heap dumps.

    When you need to browse contents of application memory or uncover a
    memory leak in your application, you'll find the built-in HeapWalker
    tool really handy. It can read files written in hprof format and is also able to browse heap dumps created by the JVM on an OutOfMemoryException.

    Analyze core dumps.

    When a Java process crashes, a core dump can be generated by the JVM
    containing important information about application state at the time of
    the crash. VisualVM is able to display application configuration and
    runtime environment and to extract thread and heap dumps from the core
    dump.

    Analyze applications offline.

    VisualVM is able to save application configuration and runtime
    environment together with all taken thread dumps, heap dumps and
    profiler snaphots into a single application snapshot which can be later
    processed offline. This is especially useful for bug reports where
    users can provide a single file containing all the necessary
    information to identify runtime environment and application state.

    visit for more details https://visualvm.dev.java.net

    Friday 2 May 2008

    Java Concurrency is the next big thing, reason why you would learn this ?

    I have recently implemented the concurrent package and basis of my experience I thought this concept is worth promoting. believe me i am a bit more techie now, because a lot of concurrency expertise comes now for free with Java :))

    First I would talk here why you would invest your time learning this piece of information when you can spend it watching some movie ? Becuase it can save you those code debugging days later..

    The Java platform includes a new package of concurrency utilities.Just as the Collections Framework simplified the organization and manipulation of in-memory data by providing implementations of commonly used data structures, the Concurrency Utilities aims to simplify the development of multithreaded applications. So in summary you have lot of things already wrapped for you.

    The Concurrency Utilities include the following in built features like
    * A high-performance, flexible thread pool
    * A framework for asynchronous execution of tasks
    * A host of collection classes optimized for concurrent access
    * A synchronization utilities such as counting semaphores, atomic variables, locks, condition variables etc etc.

    Let us put it in other words. When you need a list like data structure do you define your own list implementation ?
    when you need a map like structure you simply use some hashmap .. am I right?
    So guys something similar is this package. Solves lot of your headaches :) the only thing you need to do is a little bit of more learning :)

    Using the Concurrency Utilities, instead of developing components from scratch such as thread pools yourself, it offers a number of advantages:

    * Reduced programming effort because It is far easier to use a standard class than to develop it yourself.

    * Increased performance. The implementations in the Concurrency Utilities were developed and peer-reviewed by concurrency and performance experts, these implementations are likely to be faster and more scalable than a typical implementation, even by a skilled developer. So you got this expertise in-built in your codes for free ? don't tell anybody :)

    * Increased reliability. Developing concurrent classes is difficult atleast not easy to design -- the low-level concurrency primitives provided by the Java language (synchronized, volatile, wait(), notify(), and notifyAll()) are difficult to use correctly, and errors using these facilities can be difficult to detect and debug.
    By using standardized, extensively tested concurrency building blocks, many potential sources of threading hazards such as deadlock, starvation, race conditions, or excessive context switching are eliminated. The concurrency utilities have been carefully audited for deadlock, starvation, and race conditions.

    * Improved maintainability. Programs which use standard library classes are easier to understand and maintain than those which rely on complicated, homegrown classes.

    * Increased productivity. Developers are likely to already understand the standard library classes, so there is no need to learn the API and behavior of ad-hoc concurrent components. Additionally, concurrent applications are far simpler to debug when they are built on reliable, well-tested components.

    the Concurrency Utilities to implement a concurrent application can help you make your program clearer, shorter, faster, more reliable, more scalable, easier to write, easier to read, and easier to maintain.

    Wednesday 30 April 2008

    So what do you understand by IMMUTABLE ?

    but how do we define mutable, or immutable? I searched various Java texts but could not find a definition of what is meant by that. Let's try and define it for our use:

    Immutable Class: A class where the state cannot be changed.

    Simple enough, but what does state refer to? Is it a state descriptor of all the data members in the class? Or is it just the identity of the class? For example, let's consider the class Employee, which is part of the middle class ...

    public class Employee {
      private final String name;
      private final double salary;
      private final Date dob;
      public Employee(String name, double salary, Date dob) {
        this.name = name;
        this.salary = salary;
        this.dob = dob;
      }
      public String getName() { return name; }
      public double getSalary() { return salary; }
      public Date getDOB() { return dob; }
    }

    Is the Employee class mutable?

    If we say that the state consists of a combination of all the data members then the answer is "Yes". We need to be careful examining the object state here. Do you think its possible to change the object state from outside ?

    If not then the object definition is immutable however if you are able to change then the object is not immutable?

    General assumption is if the member variables are declared final and we only provide the accessers then the class is immutable. So let us use the above class in our code.

    public class ImmutabilityTest {
      public static void main(String[] str) {
          Employee emp = new Employee(“john”, 10000, new Date());
        //lets fetch the emp date of birth;
            Date empdob = emp.getDOB();
        //so I got the reference to the final object stored within the
        //Employee object.
            
            empdob.setMonth(10);
            //can I do this ?
            //how about the state of the original object ?? 
            }
    }

    So I created the emp object and got the dob date object reference and changed the date value empdob.setMonth(10); so I am able to change the object state.

    The key thing worth keeping in mind is the final keyword is making the refernce final. The objects state of members is still changeable through refernces.

    How you would address such issues ?

    You need to make sure that whenever you return the object, you return the copy of the object. E.g. modify the getDOB() in this case to do something like

    public Date getDOB() { return dob.clone(); }

    I am keeping the original reference within the object itself and returning the deep copy of the object to the caller.

    Some fairly good JDBC Questions 24-33

    [JDBC Questions 1-12], [JDBC Questions 13-24]

    Q25 What advantage is there to using prepared statements if I am using connection pooling or closing the connection frequently to avoid resource/connection/cursor limitations?

    The ability to choose the 'best' efficiency ( or evaluate tradeoffs, if you prefer, ) is, at times, the most important piece of a mature developer's skillset. This is YAA ( Yet Another Area, ) where that maxim applies. Apparently there is an effort to allow prepared statements to work 'better' with connection pools in JDBC 3.0, but for now, one loses most of the original benefit of prepared statements when the connection is closed. A prepared statement obviously fits best when a statement differing only in variable criteria is executed over and over without closing the statement.

    However, depending on the DB engine, the SQL may be cached and reused even for a different prepared statement and most of the work is done by the DB engine rather than the driver. In addition, prepared statements deal with data conversions that can be error prone in straight ahead, built on the fly SQL; handling quotes and dates in a manner transparent to the developer, for example.


    Q26 Why do I get an UnsupportedOperationException?

    JDBC 2.0, introduced with the 1.2 version of Java, added several capabilities to JDBC. Instead of completely invalidating all the older JDBC 1.x drivers, when you try to perform a 2.0 task with a 1.x driver, an UnsupportedOperationException will be thrown. You need to update your driver if you wish to use the new capabilities.


    Q27 Can I reuse a Statement or must I create a new one for each query?

    When using a JDBC compliant driver, you can use the same Statement for any number of queries. However, some older drivers did not always "respect the spec." Also note that a Statement SHOULD automatically close the current ResultSet before executing a new query, so be sure you are done with it before re-querying using the same Statement.


    Q28 Will a call to PreparedStatement.executeQuery() always close the ResultSet from the previous executeQuery() if you dont you yourself?

    A ResultSet is automatically closed by the Statement that generated it when that Statement is closed, re-executed, or is used to retrieve the next result from a sequence of multiple results.


    Q29 How do you convert a java.sql.Timestamp to a java.util.Date?

    While Timesteamp extends Date, it stores the fractional part of the time within itself instead of within the Date superclass. If you need the partial seconds, you have to add them back in.
    Date date = new Date(ts.getTime() + (ts.getNanos() / 1000000 ));

    Q30.What are the data access design patterns you use while writing the JDBC layers ?
    Very good and important question. the answer to the question is very long. In summary you need to describe the DAO pattern. you can use Factory + interface inheritance to write the data access layer. I would write sometime in future on this.

    Q31. When I create multiple Statements on same Connection, only the current Statement appears to be executed. What's the problem?

    All JDBC objects are required to be threadsafe. Some drivers, unfortunately, implement this requirement by processing Statements serially. This means that additional Statements are not executed until the preceding Statement is completed.

    Q32. Can a single thread open up mutliple connections simultaneously for the same database if yes how many?

    The general answer to this is yes. If that were not true, connection pools, for example, would not be possible. this is drived from the underlying database setting the max connection limit set on the database.

    Q33. What do you understand by connection timeout intervaal ?

    Every database connection has the timeout interval set (depends on database configuration). This is the max inactivity interval for any connection. If not statement is executed within this time the underlying database would invalidate the connection.

    Tuesday 29 April 2008

    The Good to Great performance in a JDBC application

    Few points to consider:

    * Use a connection pools wherever possible.

    * Use prepared statements. These can be beneficial, for example with DB specific escaping, even when used only once. use prepare once and use always strategy.

    * Use stored procedures when they can be created in a standard manner. Do watch out for DB specific SP definitions that can cause migration headaches, but only if you need to support multiple database types. Sometimes over-engineering is a overhead. Don't do something just because you can think :) . Sometimes keeping the things simple is the most desirable and admirable thing on the earth.

    * Even though the jdbc promotes portability, true portability comes from NOT depending on any database specific data types, functions and so on.

    * Select only required columns rather than using select * from Tablexyz.

    * Always close Statement and ResultSet objects as soon as possible.

    * Write modular classes to handle database interaction specifics.

    * Work with DatabaseMetaData to get information about database functionality.

    * Softcode database specific parameters with, for example, properties files.

    * Always catch AND handle database warnings and exceptions. Be sure to check for additional pending exceptions.

    * Test your code with debug statements to determine the time it takes to execute your query and so on to help in tuning your code. Also use query plan functionality if available.

    * Use proper ( and a single standard if possible ) formats, especially for dates.

    * Use proper data types for specific kind of data. For example, store birth date as a date type rather than, say, varchar.

    *Last but not the least optimize you queries understand from db point of view how the execution plan would be. Identify the queries which executed frequently and could prove bottlenecks.

    and the list goes on :)

    Some fairly good JDBC Questions 13-24

    We have the first list of 1-20 JDBC questions. here we go with another 20 :)

    Q13. How can you create JDBC statements and what are they?

    A Statement object is what sends your SQL statement to the DBMS. You simply create a Statement object and then execute it, supplying the appropriate execute method with the SQL statement you want to send. For a SELECT statement, the method to use is executeQuery. For statements that create or modify tables, the method to use is executeUpdate. It takes an instance of an active connection to create a Statement object. In the following example, we use our Connection object con to create the Statement object

    Statement stmt = con.createStatement();

    Q 14. How can you retrieve data from the ResultSet?

    JDBC returns results in a ResultSet object, so we need to declare an instance of the class ResultSet to hold our results. The following code demonstrates declaring the ResultSet object rs.

    ResultSet rs = stmt.executeQuery(”SELECT COF_NAME, PRICE FROM COFFEES”);
    String s = rs.getString(”COF_NAME”);

    The method getString is invoked on the ResultSet object rs, so getString() will retrieve (get) the value stored in the column COF_NAME in the current row of rs.

    Q15. What are the different types of Statements?

    Regular statement (use createStatement method), prepared statement (use prepareStatement method) and callable statement (use prepareCall)

    Q16. How can you use PreparedStatement?

    This special type of statement is derived from class Statement.If you need a
    Statement object to execute many times, it will normally make sense to use a PreparedStatement object instead. The advantage to this is that in most cases, this SQL statement will be sent to the DBMS right away, where it will be compiled. As a result, the PreparedStatement object contains not just an SQL statement, but an SQL statement that has been precompiled. This means that when the PreparedStatement is executed, the DBMS can just run the PreparedStatement’s SQL statement without having to compile it first.

    PreparedStatement updateSales =
    con.prepareStatement("UPDATE COFFEES SET SALES = ? WHERE COF_NAME LIKE ?");

    Q17. What does setAutoCommit do?

    When a connection is created, it is in auto-commit mode. This means that each individual SQL statement is treated as a transaction and will be automatically committed right after it is executed. The way to allow two or more statements to be grouped into a transaction is to disable auto-commit mode:

    con.setAutoCommit(false);

    Once auto-commit mode is disabled, no SQL statements will be committed until you call the method commit explicitly.

    con.setAutoCommit(false);
    PreparedStatement updateSales =
    con.prepareStatement( "UPDATE COFFEES SET SALES = 10 WHERE COF_NAME ='capacinno' ");
    updateTotal.executeUpdate();
    con.commit();

    Q18. How do you call a stored procedure from JDBC?

    The first step is to create a CallableStatement object. As with Statement an and PreparedStatement objects, this is done with an open
    Connection object. A CallableStatement object contains a call to a stored procedure.

    CallableStatement cs = con.prepareCall("{call SHOW_SUPPLIERS}");
    ResultSet rs = cs.executeQuery();

    Q19. How do I retrieve warnings?

    SQLWarning objects are a subclass of SQLException that deal with database access warnings. Warnings do not stop the execution of an
    application, as exceptions do; they simply alert the user that something did not happen as planned. A warning can be reported on a
    Connection object, a Statement object (including PreparedStatement and CallableStatement objects), or a ResultSet object. Each of these
    classes has a getWarnings method, which you must invoke in order to see the first warning reported on the calling object:

    SQLWarning warning = stmt.getWarnings();
    if (warning != null)
    {
    System.out.println("n---Warning---n");
    while (warning != null)
    {
    System.out.println("Message: " + warning.getMessage());
    System.out.println("SQLState: " + warning.getSQLState());
    System.out.print("Vendor error code: ");
    System.out.println(warning.getErrorCode());
    System.out.println("");
    warning = warning.getNextWarning();
    }
    }

    Q20. How can you move the cursor in scrollable result sets?

    One of the new features in the JDBC 2.0 API is the ability to move a result set’s cursor backward as well as forward. There are also methods that let you move the cursor to a particular row and check the position of the cursor.

    Statement stmt = con.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE, ResultSet.CONCUR_READ_ONLY);
    ResultSet srs = stmt.executeQuery(”SELECT COF_NAME, PRICE FROM COFFEES”);

    The first argument is one of three constants added to the ResultSet API to indicate the type of a ResultSet object: TYPE_FORWARD_ONLY, TYPE_SCROLL_INSENSITIVE , and TYPE_SCROLL_SENSITIVE. The second argument is one of two ResultSet constants for specifying whether a result set is read-only or updatable: CONCUR_READ_ONLY and CONCUR_UPDATABLE. The point to remember here is that if you specify a type, you must also specify whether it is read-only or updatable. Also, you must specify the type first, and because both parameters are of type int , the compiler will not complain if you switch the order. Specifying the constant TYPE_FORWARD_ONLY creates a nonscrollable result set, that is, one in which the cursor moves only forward. If you do not specify any constants for the type and updatability of a ResultSet object, you will automatically get one that is TYPE_FORWARD_ONLY and CONCUR_READ_ONLY.

    Q21. What’s the difference between TYPE_SCROLL_INSENSITIVE , and TYPE_SCROLL_SENSITIVE?
    You will get a scrollable ResultSet object if you specify one of these ResultSet constants.The difference between the two has to do with whether a result set reflects changes that are made to it while it is open and whether certain methods can be called to detect these changes. Generally speaking, a result set that is TYPE_SCROLL_INSENSITIVE does not reflect changes made while it is still open and one that is TYPE_SCROLL_SENSITIVE does. All three types of result sets will make changes visible if they are closed and then reopened:

    Statement stmt =
    con.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY);
    ResultSet srs =
    stmt.executeQuery("SELECT COF_NAME, PRICE FROM COFFEES");
    srs.afterLast();
    while (srs.previous())
    {
    String name = srs.getString("COF_NAME");
    float price = srs.getFloat("PRICE");
    System.out.println(name + " " + price);
    }

    Q22. How to Make Updates to Updatable Result Sets?

    Another new feature in the JDBC 2.0 API is the ability to update rows in a result set using methods in the Java programming language rather than having to send an SQL command. But before you can take advantage of this capability, you need to create a ResultSet object that is updatable. In order to do this, you supply the ResultSet constant CONCUR_UPDATABLE to the createStatement method.

    Connection con =
    DriverManager.getConnection("jdbc:mySubprotocol:mySubName");
    Statement stmt =
    con.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE, ResultSet.CONCUR_UPDATABLE);
    ResultSet uprs =
    stmt.executeQuery("SELECT COF_NAME, PRICE FROM COFFEES");


    Q23 What is the difference between client and server database cursors?

    What you see on the client side is the current row of the cursor which called a Result (ODBC) or ResultSet (JDBC). The cursor is a server-side entity only and remains on the server side.


    Q24 Are prepared statements faster because they are compiled? if so, where and when are they compiled?

    Prepared Statements aren't actually compiled, but they are bound by the JDBC driver. Depending on the driver, Prepared Statements can be a lot faster - if you re-use them. Some drivers bind the columns you request in the SQL statement. When you execute Connection.prepareStatement(), all the columns bindings take place, so the binding overhead does not occur each time you run the Prepared Statement. For additional information on Prepared Statement performance and binding see JDBC Performance Tips on IBM's website.

    Sunday 13 April 2008

    Some fairly good JDBC Questions 1-12

    I am quite excited with the response from my servlet questions series [Questions 1-25, Questions 26-50, Questions 51-75 ].

    So I thought of writing another one on JDBC and here we go ..

    Q1. What are four types of JDBC driver?

    Type 1 Drivers : Bridge drivers such as the jdbc-odbc bridge. They rely on an intermediary such as ODBC to transfer the SQL calls to the database and also often rely on native code. It is not a serious solution for an application

    Type 2 Drivers : Use the existing database API to communicate with the database on the client. Faster than Type 1, but need native code and require additional permissions to work in an applet. Client machine requires software to run.

    Type 3 Drivers : JDBC-Net pure Java driver. It translates JDBC calls to a DBMS-independent network protocol, which is then translated to a DBMS protocol by a server. Flexible. Pure Java and no native code.

    Type 4 Drivers : Native-protocol pure Java driver. It converts JDBC calls directly into the network protocol used by DBMSs. This allows a direct call from the client machine to the DBMS server. It doesn't need any special native code on the client machine.
    Recommended by Sun's tutorial, driver type 1 and 2 are interim solutions where direct pure Java drivers are not yet available. Driver type 3 and 4 are the preferred way to access databases using the JDBC API, because they offer all the advantages of Java technology, including automatic installation. For more info, visit Sun JDBC page

    Q2. Which type of JDBC driver is the fastest one?

    JDBC Net pure Java driver(Type IV) is the fastest driver because it converts the jdbc calls into vendor specific protocol calls and it directly interacts with the database.

    Q3. Are all the required JDBC drivers to establish connectivity to my database part of the JDK?

    No. There aren't any JDBC technology-enabled drivers bundled with the Java Platform releases other than the JDBC-ODBC Bridge. So, developers need to get a driver and install it before they can connect to a database.

    Q4. Is the JDBC-ODBC Bridge multi-threaded?

    No.

    Q5. What is the fastest type of JDBC driver?

    JDBC driver performance will depend on a number of issues:
    (a) the quality of the driver code,
    (b) the size of the driver code,
    (c) the database server and its load,
    (d) network topology,
    (e) the number of times your request is translated to a different API.
    In general, all things being equal, you can assume that the more your request and response change hands, the slower it will be. This means that Type 1 and Type 3 drivers will be slower than Type 2 drivers (the database calls are make at least three translations versus two), and Type 4 drivers are the fastest (only one translation).

    Q6. What causes the "No suitable driver" error?

    "No suitable driver" is an error that usually occurs during a call to the DriverManager.getConnection method. The cause can be failing to load the appropriate JDBC drivers before calling the getConnection method, or it can be specifying an invalid JDBC URL--one that isn't recognized by your JDBC driver. Your best bet is to check the documentation for your JDBC driver or contact your JDBC driver vendor if you suspect that the URL you are specifying is not being recognized by your JDBC driver.
    In addition, when you are using the JDBC-ODBC Bridge, this error can occur if one or more the the shared libraries needed by the Bridge cannot be loaded. If you think this is the cause, check your configuration to be sure that the shared libraries are accessible to the Bridge.

    Q7. Why isn't the java.sql.DriverManager class being found?
    Some one may ask you questions to confuse you also :) simple answer is the classpath does not contain the necessary jdk jars.

    Q8. What are the common steps to execute a Query in JDBC?

    Create an instance of a JDBC driver or load JDBC drivers through jdbc.drivers
    Register a driver
    Specify a database
    Open a database connection
    Submit a query
    Receive results
    Process results

    Q9. What are the steps involved in establishing a JDBC connection?
    This action involves two steps: loading the JDBC driver and making the connection.

    Q10. How can you load the drivers?
    Loading the driver or drivers you want to use is very simple and involves just one line of code. If, for example, you want to use the JDBC-ODBC Bridge driver, the following code will load it:

    Class.forName(”sun.jdbc.odbc.JdbcOdbcDriver”);

    Your driver documentation will give you the class name to use. For instance, if the class name is jdbc.DriverXYZ, you would load the driver with the following line of code:

    Class.forName(”jdbc.DriverXYZ”);

    Q11. What will Class.forName do while loading drivers?

    It is used to create an instance of a driver and register it with the
    DriverManager. When you have loaded a driver, it is available for making a connection with a DBMS.

    Q12. How can you make the connection?

    To establish a connection you need to have the appropriate driver connect to the DBMS.
    The following line of code illustrates the general idea:

    String url = “jdbc:odbc:Fred”;
    Connection con = DriverManager.getConnection(url, “Fernanda”, “J8?);

    Monday 17 March 2008

    Do you know Java Shutdown Hook?

    JVMs are killed and Restarted either automatically by network management systems or manually by a network administrator or by the infrastructure management teams. When a JVM is killed, it is often necessary to perform some cleanup work before the JVM finishes shutting down. How we can achieve such behaviour ?

    JVM shutdown hooks provide a clean and simple mechanism for registering application-specific behavior that performs cleanup work when a JVM terminates or its killed.

    We need to first define the shutdown hook, which is a thread which would be started automatically by JVM when it terminates. So whatever action we want to take as a part of shutdown process goes within the run method of thread.


    public class ShutdownHook extends Thread {
    public
    ShutdownHook() {
    super();
    }
    public void run() {
    System.out.println("
    ShutdownHook started ...
    do whatever you want here !!!");
    }
    }

    Once you have defines the shutdown hook whats next? How this would be invoked?
    We need to register an instance of this hook to JVM ...

       public class HookDemo() {
    public
    HookDemo() {
    ShutdownHook sh = new ShutdownHook();
    //register the hook like this ...
    Runtime.getRuntime().addShutdownHook(sh);
    }

    public static void main(String[] str ) {

    HookDemo obj = new HookDemo();
    //let us terminate the program now...
    System.exit(1);

    //what output you expect ??
    }
    }
    Output : ShutdownHook started... do whatever you want here !!!

    Let us move to more complex example now... Let us assume I have a JDBC manager in my project ... I want to make sure whenever the Application shuts down the JDBCManager#cleanup() method is always executed , which ensures we have shutdown the manager proprly.
      public class JDBCManager() {
    public
    JDBCManager() {
    ShutdownHook sh = new ShutdownHook(this);
    //register the hook like this ...
    Runtime.getRuntime().addShutdownHook(sh);
    }

    public void cleanup() {

    System.out.println(" Hold on ...
    Let me do the cleanup please .... ");

    }

    public static void main(String[] str ) {

    HookDemo obj = new HookDemo();
    //let us terminate the program now...
    System.exit(1);

    //what output you expect ??
    }
    }
    What we did is we created the shutdown hook with the manager itself and passed the manager instance to hook... why we would do that?
    In plain language : We need to do all the post shutdown related actions in hook#run() method. so its essential the hook has the necessary refernces available to take the actions.

    public class ShutdownHook extends Thread {
    private JDBCManager manager;

    public ShutdownHook(JDBCManager manager) {
    this.manager = manager;
    }

    public void run() {
    System.out.println("ShutdownHook started ...");
    //let us invoke the cleanup operation here
    manager.cleanup();
    }
    }


    The following Q&A extract from Sun java documentation addresses some of the design issues of the Shutdown Hooks API

    Isn't this what runFinalizersOnExit is for?

    You can use the Runtime.runFinalizersOnExit method, or the equivalent method in the System class, to schedule actions to take place when the VM shuts down due to exit. This technique does not, however, work for termination-triggered shutdowns. It is also is inherently unsafe, and in fact these methods were deprecated in version 1.2 of the JavaTM 2 Platform.

    Why don't you provide information as to why the VM is shutting down?

    On some platforms a native process can't distinguish a shutdown due to exit from a shutdown due to termination. Other platforms provide much richer capabilities, in some cases including notification of system suspension and restart or of imminent power failure. In short, it's impossible to generalize such information in a portable way.

    Will shutdown hooks be run if the VM crashes?

    If the VM crashes due to an error in native code then no guarantee can be made about whether or not the hooks will be run.

    Why are shutdown hooks run concurrently? Wouldn't it make more sense to run them in reverse order of registration?

    Invoking shutdown hooks in their reverse order of registration is certainly intuitive, and is in fact how the C runtime library's atexit procedure works. This technique really only makes sense, however, in a single-threaded system. In a multi-threaded system such as Java platform the order in which hooks are registered is in general undetermined and therefore implies nothing about which hooks ought to be run before which other hooks. Invoking hooks in any particular sequential order also increases the possibility of deadlocks. Note that if a particular subsystem needs to invoke shutdown actions in a particular order then it is free to synchronize them internally.

    Why are hooks just threads, and unstarted ones at that? Wouldn't it be simpler to use Runnable objects, or Beans-style event and listener patterns?

    The approach taken here has two advantages over the more obvious, and more frequently suggested, callback-oriented designs based upon Runnable objects or Beans-style event listeners.

    First, it gives the user complete control over the thread upon which a shutdown action is executed. The thread can be created in the proper thread group, given the correct priority, context, and privileges, and so forth.

    Second, it simplifies both the specification and the implementation by isolating the VM from the hooks themselves. If shutdown actions were executed as callbacks then a robust implementation would wind up having to create a separate thread for each hook anyway in order for them to run concurrently. The specification would also have to include explicit language about how the threads that execute the callbacks are created.

    Aren't threads pretty expensive things to keep around, especially if they won't be started until the VM shuts down?

    Most implementations of the Java platform don't actually allocate resources to a thread until it's started, so maintaining a set of unstarted threads is actually very cheap. If you look at the internals of java.lang.Thread you can see that its various constructors just do security checks and initialize private fields. The native start() method does the real work of allocating a thread stack, etc., to get things going.

    What about Personal and Embedded Java? Won't starting threads during shutdown be too expensive on those platforms?

    This API may not be suitable for the smaller Java platforms. Threads in the Java 2 Platform carry more information than threads in JDK 1.1 and p/eJava. A thread has a class loader, it may have some inherited thread-local variables, and, in the case of GUI apps, it may be associated with a specific application context. Threads will come to carry even more information as the platform evolves; for example, the security team is planning to introduce a notion of per-thread user identity in their upcoming authentication framework.

    Because of all this contextual information, shutdown hooks would be harder to write and maintain if they were just Runnable objects or Beans-style event listeners. Suppose that a Runnable shutdown hook, or an equivalent event listener, needed a specific bit of thread-contextual information in order to carry out its operations. Such information could be saved in some shared location before the hook is registered. While this is merely awkward, suppose further that threads acquire some new type of contextual information in a future release. If an operation invoked by the hook also evolves to need that information then the code that registers the hook would have to be amended to save that information as well. Making hooks be threads instead of Runnables or event listeners insulates them from this sort of future change.

    Okay, but won't I have to write a lot of code just to register a simple shutdown hook?

    No. Simple shutdown hooks can often be written as anonymous inner classes, as in this example:

    Runtime.getRuntime().addShutdownHook(new Thread() {

    public void run() { database.close(); }

    });

    This idiom is fine as long as you'll never need to cancel the hook, in which case you'd need to save a reference to the hook when you create it.

    What about security? Can an untrusted applet register a shutdown hook?

    If there is a security manager installed then the addShutdownHook and removeShutdownHook methods check that the caller's security context permits RuntimePermission("shutdownHooks"). An untrusted applet will not have this permission, and will therefore not be able to register or de-register a shutdown hook.

    What happens if a shutdown hook throws an exception and the exception is not caught?

    Uncaught exceptions are handled in shutdown hooks just as in any other thread, by invoking the uncaughtException method of the thread's ThreadGroup object. The default implementation of this method prints the exception's stack trace to System.err and terminates the thread. Note that uncaught exceptions do not cause the VM to exit; this happens only when all non-daemon threads have finished or when the Runtime.exit method is invoked.

    Why did you add the Runtime.halt method? Isn't it pretty dangerous?

    The new halt method is certainly powerful, and it should be used with the utmost caution. It's provided so that applications can insulate themselves from shutdown hooks that deadlock or run for inordinate amounts of time. It also allows applications to force a quick exit in situations where that is necessary.

    What happens if finalization-on-exit is enabled? Will finalizers be run before, during, or after shutdown hooks?

    Finalization-on-exit processing is done after all shutdown hooks have finished. Otherwise a hook may fail if some live objects are finalized prematurely.


    Thursday 13 March 2008

    How to invoke a stored procedure using JDBC

    The very first thing you need to know is the Stored Procedure signatures.
    what is the name of the stored procedure?
    does the stored procedure have any return type?
    how many parameters it takes and which parameters are of type OUT or INOUT?

    stored procedures are of basically 3 types "in", "out" "inout"
    1) "in" is the default type. such parameters are the ones which are used to pass the value to stored procedure when we invoke the procedure.
    e.g. lets us say we have int sum(n1 int, n2 int)
    here n1 and n2 are the in parameters and sum is returned through return type int.

    2) "out" : Some stored procedures return values through parameters. When a parameter in a SQL statement or stored procedure is declared as "out", the value of the parameter is returned back to the caller.

    3) "inout" : this is both "in" and "out". when the procedure is called the value is passed in this parameter and stored procedure returns the value back to caller in this parameter.

    Another SQL question... whats difference between a function and a procedure ?
    simple question :) If you don't know the answer ... then you need to do some homework on your SQL skills first :)

    Inovking any Stored procedure from JDBC is a 6 step process.

    Step - I : Define the call for SP.
    e.g. Lets us assume I have a SQL function int sum(n1 int, n2 int)
    so calling sum requires n1 and n2 as inputs and it returns the result.
    I would write my call as String spCall ="{ ? = call sum(?, ?)}";

    If I have a SQL Procedure sum(n1 int, n2 int, n3 int OUT)
    this implies the procedure requires 2 input parameters and we get the result in 3rd parameter. In this case the call would be String spCall ="{call sum(?, ?, ?)}";

    I have a SQL Procedure sum(n1 int, n2 int INOUT)
    This implies the procedure requires 2 input parameters and we get the result in 2nd parameter itself. In this case the call would be String spCall ="{call sum(?, ?)}";

    Isn't it quite simple?

    Lets us complete all the next steps with ex. (1)
    So the call is String spCall = "{ ? = call sum(?, ?)}";

    Step-II : The next step is to define the CallableStatement object. CallableStatements facilitate a JDBC program to execute any valid SQL Block or Procedures. So we would define a callablestatement for our spCall as follows

    CallableStatement sp = con.prepareCall(spCall);

    Step III : Identify all the OUT or INOUT parameters type and register them. What do I mean by register ? This meant 2 things
    1) What is the index of such parameters.
    2) What type of value these parameters will return. now how do we specify type. JDBC have java.sql.Types which identifies the type of a sql parameters e.g. Types.INT identifies integers, Types.LONG indentifies LONG ... what would be Types.STRING?

    now given above facts what will happen with our sum example? don't you agree the first parameter is the one which would contain the results and type would be int.
    so here we go ...

    sp.registerOUTParameter(1, TYPES.Types);

    STEP-IV : Set all the input parameters which the stored procedure needs for invocation. This is very similar to how we use prepared statements. Take this statement as a thumb rule.
    e.g. let us say we want to invoke sum with n1=10 and n2=20
    sp.setInt(2, 10)
    sp.setInt(3, 20)
    This is what i meant. I set 2nd parameter with value 10 and 3rd parameter value 20.

    All is set now....

    Step V: The most straightforward one .. call execute on the sp
    sp.execute()
    This would execute the procedure...


    Step VI : Reap what you sow ... Time to get the results out ..
    We would fetch the results from the stored procedure . This is very similar to how you retrieve values from ResultSet. Again a Thumb rule.

    int sum_n1_n2 = sp.getInt(1)

    did you noticed 2 things here. 1) I called getInt(). because I registered the out parameter parameter as an Int in step III
    2) I called getInt(1) because index "1" is registered as an out parameter in step III.

    and this completed the 6 step process. Now this is the most generalized set of sequences you need to invoke any stored procedure. Any of these steps become optional depending upon the fact what your SP signatures demand.

    Wednesday 12 March 2008

    common mistake on statements

    Most of the memory leaks that I have seen with Java occurred when developers forgot to close database statements. a mistake in closing logic propagates to many places.
    Generally I keep my JDBC program structure as follows

    PreparedStatement st=null, st2 = null ....
    Connection con = null ....

    try {
    //your JDBC code goes here ....
    con = ConnectionMgr.getConnection(); //get the connection from a connection broker class...
    st = con.prepareStatement(
    "INSERT INTO subscribers (name, email) VALUE (?, ?)");
    st.setString(1, name);
    st.setString(2, email);
    st.executeUpdate();
    ..
    ..
    ..
    }
    catch(SQLException e) {
    //handle or log exception
    }
    finally {
    //ensure in finally all the resources are collected...
    try {
    if(st!=null) {
    st.close();
    }
    if(st2!=null) {
    st2.close()
    }
    if(con!=null) {
    con.close();
    }
    }
    catch(SQLException e) {
    //handle or log exception ...
    }
    }

    I have to write atleast 10 additonal lines to make sure whatever I have opened is closed properly.
    I have heard people saying .. why to bother about closing the connections/statements the garbage collector is there to do the job :)
    Dear friends the garbage collector is never going to do this for you .. if you are relying on GC to do this job for you then be prepared for worst things coming your way.
    If you don't close the connections what is going to happen?
    Every database has a timeout set on a connection. if the connection does not do any activity for that time period the database is going to expire the connection. so if you dont close the connection yourself the connection would be stake untill its clotimedout. so greater is the timeout value the higher is the time such orphaned connections are sitting in JVM, eventually its possible that your application runs out of limit for the maximum possible connections to the database.

    However, the problem still remains of how to write code that closes the statements and result sets reliably. You want to always attempt to close the statements, whether an exception occurs or not. In the Jakarta Commons DbUtils project, functions are provided to ensure that your statements are also always closed.

    JDBC resource cleanup code is mundane, error prone work so these classes abstract out all of the cleanup tasks from your code leaving you with what you really wanted to do with JDBC in the first place: query and update data.

    This is how you would use its QueryRunner:

    import org.apache.commons.dbutils.QueryRunner;
    import java.sql.*;

    public class Database2 {
    private QueryRunner queryRunner = new QueryRunner();
    public int insertSubscriber(Connection con, String name, String email)
    throws SQLException {
    String sql = "INSERT INTO subscribers (name, email) VALUE (?, ?)";
    Object[] params = { name, email };
    return queryRunner.update(con, sql, params);
    }
    }

    There are very good features available in DB utils e.g. for a given select query ResultSet you can associate the java beans and when you fire the query you get the collection of associated java objects. please have a look at Examples here.

    Why Prepared Statements are important?

    Databases have a tough job. They accept SQL queries from many clients concurrently and execute the queries as efficiently as possible against the data. Processing statements can be an expensive operation but databases are now written in such a way so that this overhead is minimized. However, these optimizations need assistance from the application developers if we are to capitalize on them. This article shows you how the correct use of PreparedStatements can significantly help a database perform these optimizations.

    How does a statement is executed ?

    From JDBC perspective when a database receives a statement, the database engine first parses the statement and looks for syntax errors. Once the statement is parsed, the database needs to figure out the most efficient way to execute the statement. This can be quite expensive task. The database checks what indexes, if any, can help, or whether it should do a full read of all rows in a table. Databases use statistics on the data to figure out what is the best way and finally we get a Query execution plan. Once the query plan is created then it can be executed by the database engine.

    Everytime we execute a sql query all these jobs are repeated again and again.

    Statement Caches
    Databases are tuned to do statement caches. They usually include some kind of statement cache. This cache uses the statement itself as a key and the access plan is stored in the cache with the corresponding statement. This allows the database engine to reuse the plans for statements that have been executed previously. For example, if we sent the database a statement such as "select a,b from t where c = 2", then the computed access plan is cached. If we send the same statement later, the database can reuse the previous access plan, thus saving us CPU power.

    Note however, that the entire statement is the key. For example, if we later sent the statement "select a,b from t where c = 3", it would not find an access plan. This is because the "c=3" is different from the cached plan "c=2". So, for example:

    For(int I = 0; I < 1000; ++I)
    {
    PreparedStatement ps = conn.prepareStatement("select a,b from t where c = " + I);
    ResultSet rs = Ps.executeQuery();
    Rs.close();
    Ps.close();
    }

    Here the cache won't be effective. Each iteration of the loop sends a different SQL statement to the database (Why ? I is changing for each iteration as a result sql query is different for each iteration). A new access plan is computed for each iteration and we're basically throwing CPU cycles away using this approach. However, look at the next snippet:

    PreparedStatement ps = conn.prepareStatement("select a,b from t where c = ?");
    //We are using the sql parametrized form ... kinda skeleton query ...
    For(int I = 0; I < 1000; ++I)
    {
    ps.setInt(1, I);
    ResultSet rs = ps.executeQuery();
    Rs.close();
    }
    ps.close();

    Here it will be much more efficient. The statement sent to the database is parameterized using the '?' marker in the sql. This means every iteration is sending the same statement to the database with different parameters for the "c=?" part. This allows the database to reuse the access plans for the statement and makes the program execute more efficiently inside the database. This basically let's your application run faster or makes more CPU available to users of the database.

    PreparedStatements and J2EE servers

    Things can get more complicated when we use a J2EE server. Normally, a prepared statement is associated with a single database connection. When the connection is closed, the preparedstatement is discarded. Normally, a fat client application would get a database connection and then hold it for its lifetime. It would also create all prepared statements eagerly or lazily. Eagerly means that they are all created at once when the application starts. Lazily means that they are created as they are used. An eager approach gives a delay when the application starts but once it starts then it performs optimally. A lazy approach gives a fast start but as the application runs, the prepared statements are created when they are first used by the application. This gives an uneven performance until all statements are prepared but the application eventually settles and runs as fast as the eager application. Which is best depends on whether you need a fast start or even performance.

    The problem with a J2EE application is that it can't work like this. It only keeps a connection for the duration of the request. This means that it must create the prepared statements every time the request is executed. This is not as efficient as the fat client approach where the prepared statements are created once, rather than on every request. J2EE vendors have noticed this and designed connection pooling to avoid this performance disadvantage.

    When the J2EE server gives your application a connection, it isn't giving you the actual connection; you're getting a wrapper. You can verify this by looking at the name of the class for the connection you are given. It won't be a database JDBC connection, it'll be a class created by your application server. Normally, if you called close on a connection then the jdbc driver closes the connection. We want the connection to be returned to the pool when close is called by a J2EE application. We do this by making a proxy jdbc connection class that looks like a real connection. It has a reference to the actual connection. When we invoke any method on the connection then the proxy forwards the call to the real connection. But, when we call methods such as close instead of calling close on the real connection, it simply returns the connection to the connection pool and then marks the proxy connection as invalid so that if it is used again by the application we'll get an exception.

    Wrapping is very useful as it also helps J2EE application server implementers to add support for prepared statements in a sensible way. When an application calls Connection.prepareStatement, it is returned a PreparedStatement object by the driver. The application then keeps the handle while it has the connection and closes it before it closes the connection when the request finishes. However, after the connection is returned to the pool and later reused by the same, or another application, , then ideally, we want the same PreparedStatement to be returned to the application.

    J2EE PreparedStatement Cache

    J2EE PreparedStatement Cache is implemented using a cache inside the J2EE server connection pool manager. The J2EE server keeps a list of prepared statements for each database connection in the pool. When an application calls prepareStatement on a connection, the application server checks if that statement was previously prepared. If it was, the PreparedStatement object will be in the cache and this will be returned to the application. If not, the call is passed to the jdbc driver and the query/preparedstatement object is added in that connections cache.

    We need a cache per connection because that's the way jdbc drivers work. Any preparedstatements returned are specific to that connection.

    If we want to take advantage of this cache, the same rules apply as before. We need to use parameterized queries so that they will match ones already prepared in the cache. Most application servers will allow you to tune the size of this prepared statement cache.
    Summary

    In conclusion, we should use parameterized queries with prepared statements. This reduces the load on the database by allowing it to reuse access plans that were already prepared. This cache is database-wide so if you can arrange for all your applications to use similar parameterized SQL, you will improve the efficiency of this caching scheme as an application can take advantage of prepared statements used by another application. This is an advantage of an application server because logic that accesses the database should be centralized in a data access layer (either an OR-mapper, entity beans or straight JDBC).

    Finally, the correct use of prepared statements also lets you take advantage of the prepared statement cache in the application server. This improves the performance of your application as the application can reduce the number of calls to the JDBC driver by reusing a previous prepared statement call. This makes it competitive with fat clients efficiency-wise and removes the disadvantage of not being able to keep a dedicated connection.

    If you use parameterized prepared statements, you improve the efficiency of the database and your application server hosted code. Both of these improvements will allow your application to improve its performance.

    Thursday 14 February 2008

    How to make JDBC Connection? very simple :)

    Before we can do any database related operation like queries or stored procedure calls, we first establish a connection to the database. Fundamentally there are 2 ways you can connect to database. Here I will talk about how we connect through JDBC type-IV drivers, because type-IV are what we use most of the time.
    1) DriverManager
    2) DataSource

    Before we start our discussion on how to make a connection, first we make some setups right.
    1) Make sure that you have appropriate JDBC driver available, which is generally a jar file. e.g. classes14.jar for oracle, jconnect.jar for sybase etc.
    2) Make sure this driver jar file is in your classpath. e.g. in Eclipse you can add the jar file in your classpath like following

    I am listing below the JDBC driver download locations. Please choose the appropriate one for your requirements if you don't have the one.











  • To add the JAR to the project classpath. Right-click on the project and select "Properties". Go to the "Libraries" tab in "Java Build Path" and click "Add External Jars" button



    Select the relevant driver jar Click "OK"



    Thats it!!!

    Defining the Connection URL is the key to connect to the database successfully. The connection URL basically consist of 3 parts
    a) The database hostname e.g. localhost
    b) The databse port number e.g. 1531
    c) additional info e.g. database name for mysql or serviceId for oracle.

    The connection URLs are different for different drivers and databases. you are adviced to always consult the driver documentation to know the connection URL formats.

    Generally the formats for different database drivers are follwoing.
    Oracle :
    JDBC Driver : oracle.jdbc.OracleDriver
    JDBC Connection URL : jdbc:oracle:thin:@<host_name>:<port_number>:<database_name>
    Click here for more help

    My-SQL :
    JDBC Driver : org.gjt.mm.mysql.Driver
    JDBC Connection URL : jdbc:mysql://<host_name>:<port_number>/<database_name>
    Click here for more Help

    Sybase :
    JDBC Driver : com.sybase.jdbc3.jdbc.SybDriver
    JDBC Connection URL : jdbc:sybase:Tds:<host_name>:<port_number>/<database_name>
    Click here for more Help

    MS-SQL :
    JDBC Driver : com.microsoft.jdbc.sqlserver.SQLServerDriver
    JDBC URL : jdbc:microsoft:sqlserver://<host_name>:<port_number>;DatabaseName=<database_name>
    Click here for more Help

    The next is the username/password information to establish the JDBC connection.
    Once we have all these things in place we can start with writing programs for database operations.

    A) JDBC Connection using DriverManager:
    1) Register the Driver: Registering the driver instructs JDBC Driver Manager which driver to load. We should know the driver class beforehand and I have listed a few already.
    We either use Class.forName() or DriverManager.registerDriver().
    2) Call DriverManager.getConnection(String connectionURL, String username, String password) to get the JDBC connection.

    The following sample code demonstrates how to register the driver and get the connection for different databases:

    MS-SQL :
    Class.forName("com.microsoft.jdbc.sqlserver.SQLServerDriver").newInstance();
    Connection con = DriverManager.getConnection("jdbc:microsoft:sqlserver://localhost:1433;DatabaseName=databaseName", "userName", "password");

    Oracle :
    e.g. if serviceId is orcl (default) and port number is 1521
    DriverManager.registerDriver (new oracle.jdbc.driver.OracleDriver());
    Connection conn = DriverManager.getConnection("jdbc:oracle:thin:@hostname:1521:orcl", "scott", "tiger");

    My-SQL:
    Class.forName("org.gjt.mm.mysql.Driver");
    Connection con = DriverManager.getConnection("jdbc:mysql://<host_name>:<port_number>/<database_name>", "sa", "sa");


    One of the biggest mistakes we make in our JDBC development is to hardcode configuration information. While everyone realize the fact but it does still happen. Another big mistake is to distribute similar setup information throughout your application, making it really hard to find all the places when you need to change or refactor.

    This seems to happen quite frequently with database drivers. There might be several instances of Class.forName("...") for loading the correct driver. In addition, the connection URL, username and password could be hardcoded or read from obscure config files. The desirable behaviour is to centralize such managements as far as possible.

    It is sometimes quite useful to know how long a database statement takes to complete and how frequently it is called. A great tool for this is JAMon. In the latest edition, they have support for monitoring JDBC calls. All that you need to do is use their JDBC driver, point it to your driver, and you're done. This is extremely easy when all the config is in one place, but if you are connecting to several databases in various locations in your codebase, it will require code changes. Ideally we should not need any code changes.

    B) JDBC Connection using DataSource:
    In-Progress