Miscellaneous Resource Management

Exception Handling

XML Resource Management

Using Oracle XML DB

OCA Resource Management

OCA

OCA Notes, RR-Date-Format-Element , Date and TimeStamp, OCA Preparation

Singleton Pattern

With the Singleton design pattern you can:

1. Ensure that only one instance of a class is created
2. Provide a global point of access to the object
3. Allow multiple instances in the future without affecting a singleton class's clients

The figure below illustrates the Singleton design pattern class diagram



Singletons maintain a static reference to the sole singleton instance and return a reference to that instance from a static instance() method.

Condider the following design implementation

Example 1. The classic singleton

public class ClassicSingleton {
private static ClassicSingleton instance = null;
protected ClassicSingleton() {
// Exists only to defeat instantiation.
}
public static ClassicSingleton getInstance() {
if(instance == null) {
instance = new ClassicSingleton();
}
return instance;
}
}

The ClassicSingleton class maintains a static reference to the lone singleton instance and returns that reference from the static getInstance() method.

There are several interesting points concerning the ClassicSingleton class.

First, ClassicSingleton employs a technique known as lazy instantiation to create the singleton; as a result, the singleton instance is not created until the getInstance() method is called for the first time. This technique ensures that singleton instances are created only when needed.

Second, notice that ClassicSingleton implements a protected constructor so clients cannot instantiate ClassicSingleton instances; however, you may be surprised to discover that the following code is perfectly legal:

public class SingletonInstantiator {
public SingletonInstantiator() {
ClassicSingleton instance = ClassicSingleton.getInstance();
ClassicSingleton anotherInstance =
new ClassicSingleton();
...
}
}

How can the class in the preceding code fragment—which does not extend ClassicSingleton—create a ClassicSingleton instance if the ClassicSingleton constructor is protected? The answer is that protected constructors can be called by subclasses and by other classes in the same package. Because ClassicSingleton and SingletonInstantiator are in the same package (the default package), SingletonInstantiator() methods can create ClassicSingleton instances. This dilemma has two solutions: You can make the ClassicSingleton constructor private so that only ClassicSingleton() methods call it; however, that means ClassicSingleton cannot be subclassed. Sometimes, that is a desirable solution; if so, it's a good idea to declare your singleton class final, which makes that intention explicit and allows the compiler to apply performance optimizations. The other solution is to put your singleton class in an explicit package, so classes in other packages (including the default package) cannot instantiate singleton instances.

A third interesting point about ClassicSingleton: it's possible to have multiple singleton instances if classes loaded by different classloaders access a singleton. That scenario is not so far-fetched; for example, some servlet containers use distinct classloaders for each servlet, so if two servlets access a singleton, they will each have their own instance.

Fourth, if ClassicSingleton implements the java.io.Serializable interface, the class's instances can be serialized and deserialized. However, if you serialize a singleton object and subsequently deserialize that object more than once, you will have multiple singleton instances.

Finally, and perhaps most important, Example 1's ClassicSingleton class is not thread-safe. If two threads—we'll call them Thread 1 and Thread 2—call ClassicSingleton.getInstance() at the same time, two ClassicSingleton instances can be created if Thread 1 is preempted just after it enters the if block and control is subsequently given to Thread 2.

Design Patterns

Observer Pattern ,
Inversion of Control Pattern ,
Singleton Pattern-1,
Singleton Pattern-2,
MVC Model-1 & Model-2,
IOCBeginners

Design Patterns

Design patterns are an extremely powerful tool for a developer or architect actively engaged in any development project. Design patterns ensure that common problems are addressed via well-known and accepted solutions. The fundamental strength of patterns rests with the fact that most problems have likely been encountered and solved by other individuals or development teams. As such, patterns provide a mechanism to share workable solutions between developers and organizations. This ensures that correct code is developed more rapidly and reduces the chance that a mistake will occur in design or implementation.

Just as object-oriented programming encourages code reuse, design patterns encourage design reuse.

In order to properly use a design pattern in your design, you must uphold three criteria

Understand your problem
Understand the pattern
Understand how the pattern solves your problem

Factory Methods

The factory method pattern is an object-oriented design pattern. It deals with the problem of creating objects (products) without specifying the exact class of object that will be created. The factory method design pattern handles this problem by defining a separate method for creating the objects, which subclasses can then override to specify the derived type of product that will be created. More generally, the term factory method is often used to refer to any method whose main purpose is creation of objects.

Let's consider an example.

Every program needs a way to report errors. Consider the following interface:

Listing 1
public interface Trace {
// turn on and off debugging
public void setDebug( boolean debug );
// write out a debug message
public void debug( String message );
// write out an error message
public void error( String message );
}

Suppose that you've written two implementations. One implementation (Listing 2) writes the messages out to the command line, while another (Listing 3) writes them to a file.

Listing 2
public class FileTrace implements Trace {
private java.io.PrintWriter pw;
private boolean debug;
public FileTrace() throws java.io.IOException {
// a real FileTrace would need to obtain the filename somewhere
// for the example I'll hardcode it
pw = new java.io.PrintWriter( new java.io.FileWriter( "c:\trace.log" ) );
}
public void setDebug( boolean debug ) {
this.debug = debug;
}
public void debug( String message ) {
if( debug ) { // only print if debug is true
pw.println( "DEBUG: " + message );
pw.flush();
}
}
public void error( String message ) {
// always print out errors
pw.println( "ERROR: " + message );
pw.flush();
}
}

Listing 3
public class SystemTrace implements Trace {
private boolean debug;
public void setDebug( boolean debug ) {
this.debug = debug;
}
public void debug( String message ) {
if( debug ) { // only print if debug is true
System.out.println( "DEBUG: " + message );
}
}
public void error( String message ) {
// always print out errors
System.out.println( "ERROR: " + message );
}
}

To use either of these classes, you would need to do the following:

Listing 4

//... some code ...
SystemTrace log = new SystemTrace();
//... code ...
log.debug( "entering loog" );
// ... etc ...

Now if you want to change the Trace implementation that your program uses, you'll need to edit each class that instantiates a Trace implementation. Depending upon the number of classes that use Trace, it might take a lot of work for you to make the change. Plus, you want to avoid altering your classes as much as possible.
A factory method lets us be a lot smarter about how our classes obtain Trace implementation instances:

Listing 5
public class TraceFactory {
public static Trace getTrace() {
return new SystemTrace();
}
}

getTrace() is a factory method. Now, whenever you want to obtain a reference to a Trace, you can simply call TraceFactory.getTrace():

Listing 6
//... some code ...
Trace log = new TraceFactory.getTrace();
//... code ...
log.debug( "entering loog" );
// ... etc ...

Using a factory method to obtain an instance can save you a lot of work later. In the code above, TraceFactory returns SystemTrace instances. Imagine again that your requirements change and that you need to write your messages out to a file. However, if you use a factory method to obtain your instance, you need to make only one change in one class in order to meet the new requirements. You do not need to make changes in every class that uses Trace. Instead you can simply redefine getTrace():

Listing 7
public class TraceFactory {
public static Trace getTrace() {
try {
return new FileTrace();
} catch ( java.io.IOException ex ) {
Trace t = new SystemTrace();
t.error( "could not instantiate FileTrace: " + ex.getMessage() );
return t;
}
}
}

Further, factory methods prove useful when you're not sure what concrete implementation of a class to instantiate. Instead, you can leave those details to the factory method.

In the above examples your program didn't know whether to create FileTrace or SystemTrace instances. Instead, you can program your objects to simply use Trace and leave the instantiation of the concrete implementation to a factory method

Miscellaneous Java Code

Fetching Line Number in Java Code

1.
new Throwable()).getStackTrace()[0].getLineNumber()

2.

StackTraceElement[] st = Thread.currentThread().getStackTrace();
int lineNumber = st [st.length-1].getLineNumber();

Getting a stack trace can be slow. Using this to do logging can adversely effect the performance of an application.

Observer Pattern

The Observer pattern allows the subject and observer to form a publish-subscribe relationship. Through the Observer pattern, observers can register to receive events from the subject. When the subject needs to inform its observers of an event, it simply sends the event to each observer.

The benefit: it decouples the observer from the subject. The subject doesn't need to know anything special about its observers. Instead, the subject simply allows observers to subscribe. When the subject generates an event, it simply passes it to each of its observers.

Consider the following Java example

public interface Subject {
public void addObserver( Observer o );
public void removeObserver( Observer o );
}

In the code above, the Subject interface defines the methods that a Subject must implement in order for Observers to add and remove themselves from the Subject.

public interface Observer {
public void update( Subject o );
}

The Observer interface (above) lists the methods that an Observer must implement so that a Subject can send an update notification to the Observer.

Let's consider a simple implementation of Subject -- an IntegerDataBag:

import java.util.ArrayList;
import java.util.Iterator;
public class IntegerDataBag implements Subject {
private ArrayList list = new ArrayList();
private ArrayList observers = new ArrayList();
public void add( Integer i ) {
list.add( i );
notifyObservers();
}
public Iterator iterator() {
return list.iterator();
}
public Integer remove( int index ) {
if( index < i =" (Integer)" i =" observers.iterator();" o =" (">

IntegerDataBag holds onto Integer instances. The IntegerDataBag also allows Observers to add and remove themselves.

Consider these two implementations of Observer -- IntegerAdder and IntegerPrinter:

import java.util.Iterator;
public class IntegerAdder implements Observer {
private IntegerDataBag bag;
public IntegerAdder( IntegerDataBag bag ) {
this.bag = bag;
bag.addObserver( this );
}
public void update( Subject o ) {
if( o == bag ) {
System.out.println( "The contents of the IntegerDataBag have changed." );
int counter = 0;
Iterator i = bag.iterator();
while( i.hasNext() ) {
Integer integer = ( Integer ) i.next();
counter+=integer.intValue();
}
System.out.println( "The new sum of the integers is: " + counter );
}
}
}

import java.util.Iterator;
public class IntegerPrinter implements Observer {
private IntegerDataBag bag;
public IntegerPrinter( IntegerDataBag bag ) {
this.bag = bag;
bag.addObserver( this );
}
public void update( Subject o ) {
if( o == bag ) {
System.out.println( "The contents of the IntegerDataBag have changed." );
System.out.println( "The new contents of the IntegerDataBag contains:" );
Iterator i = bag.iterator();
while( i.hasNext() ) {
System.out.println( i.next() );
}
}
}
}

IntegerAdder and IntegerPrinter add themselves to the integer bag as observers. When an IntegerAdder receives an update, it sums up the Integer values held in the bag and displays them. Likewise, when IntegerPrinter receives an update, it prints out the Integers held in the bag.

Here is a simple main() that exercises these classes:

public class Driver {
public static void main( String [] args ) {
Integer i1 = new Integer( 1 ); Integer i2 = new Integer( 2 );
Integer i3 = new Integer( 3 ); Integer i4 = new Integer( 4 );
Integer i5 = new Integer( 5 ); Integer i6 = new Integer( 6 );
Integer i7 = new Integer( 7 ); Integer i8 = new Integer( 8 );
Integer i9 = new Integer( 9 );
IntegerDataBag bag = new IntegerDataBag();
bag.add( i1 ); bag.add( i2 ); bag.add( i3 ); bag.add( i4 );
bag.add( i5 ); bag.add( i6 ); bag.add( i7 ); bag.add( i8 );
IntegerAdder adder = new IntegerAdder( bag );
IntegerPrinter printer = new IntegerPrinter( bag );
// adder and printer add themselves to the bag
System.out.println( "About to add another integer to the bag:" );
bag.add( i9 );
System.out.println("");
System.out.println("About to remove an integer from the bag:");
bag.remove( 0 );
}
}

J2SE 5.0 Language Features

J2SE5.0 has the following noteworthy language features.

Enhanced For Loop

The new enhanced for loop provides a simple, consistent syntax for iterating over collections and arrays.

Consider the following example. A collection companies contains the following names: Sun, BEA Weblogic, Oracle.

Accessing the collection without enhanced loop.

for(Iterator it = companies.iterator();it.hasNext();){//Line1
String cmp = (String)it.next();//Line2
System.out.println(cmp);
}

We need to declare Iterator(Line1), type cast the value(Line2) to access the value.

This is prone to error for the following reasons.
1. Use of Iterator
2. TypeCasting, since the Type of data in Collection companies might not be known until run-time.

Accessing the collection with enhanced loop.

for(String it:companies){
System.out.println(it);
}

The use of : reads as for each string it in companies. This approach is cleaner and robust. It does not make use of Iterator and TypeCasting is not required(The compiler takes care of these thing in background).

Enhanced loop Limitations

It cannot be used to traverse collection in which we need to add or remove entries.

for(Iterator it = companies.iterator();it.hasNext();){
if(it.next().equals("Oracle")){
it.remove();
}
}

From the above code we can see that in order to remove Oracle from the collection, we need to iterate the collection.

Sample Code For Enhance for Loop

public void EnhancedForLoop() {
List companies = new ArrayList();

companies.add("Sun");
companies.add("BEA Weblogic");
companies.add("Oracle");

// Without Enhanced
for (Iterator it = companies.iterator(); it.hasNext();) {
String cmp = (String) it.next();
System.out.println(cmp);
}

// With Enhanced
for (String it : companies) {
System.out.println(it);
}

// Without Enhanced
for (Iterator it = companies.iterator(); it.hasNext();) {
if (it.next().equals("Oracle")) {
it.remove();
}
}
System.out.println(companies);
}

Annotations

Generics

Java synchronization Vs Oracle locking

The choice between using java synchronized block or oracle row locking mechanism, while accessing database row can be determined by understanding the following scenario.

Consider the following example. There are 1000 people who apply for job in XYZ Company. The details of the applicants are stored in database table, EMP_DETAILS. The table contains various columns one of which is STATUS. The STATUS column has the default value as ‘not-verified’. The STATUS column is used to verify whether the applicant details, applying for job, are verified or not.

There are 5 employees in company XYZ, who use a web based application, to access these details from database. The query that is used to perform the database search is SELECT * FROM EMP_DETAILS WHERE STATUS=’not-verified’. Once the details are verified by these employees, the status is updated as ‘verified’.

If 5 employees are using the web application simultaneously, it is possible that more than one employee to access the same record from database i.e, more than one employee is viewing the details of the same applicant, since the query is SELECT * FROM EMP_DETAILS WHERE STATUS=’not-verified’. If both the employees make some changes to the record, it can cause data inconsistency.

Java provide a mechanism to handle this scenario by putting the code in synchronized block, and change the status of the STATUS as ‘locked’. This synchronized block should be common code that is used by all the thread in a web application.

synchronized (this){
//Fetch a record from database.
//SELECT * FROM EMP_DETAILS WHERE STATUS=’not-verified’
//change the STATUS as ‘locked’ so that it is not visible to other threads.
}

The synchronized block ensures that only one thread can enter the block at any given point of time. The other thread cannot enter the block until the first thread exits the block.
The thread that first enters into synchronized block will fetch a record from database, and change its STATUS as ‘locked’ so that it is not visible to other threads, since the query to fetch the record is SELECT * FROM EMP_DETAILS WHERE STATUS=’not-verified’.

This concept works fine if the code is deployed in non-clustered environment, where there is only one instance of servlets, containing the synchronized block. In clustered environment, there are multiple instances of web applications accessing the database simultaneously. Each cluster will have identical servlets and the synchronized block.

While accessing web application in clustered environment, the request from different users can end up on different clusters. As a result the synchronized block on different clusters can execute simultaneously, and it is possible for different web user to access the same record at any given point of time.

Synchronization ensures that out of all the threads in a cluster, only one thread can enter the synchronized block and access a database record. But this does not prevent the thread in other cluster to access the same database record, since synchronization of thread manages the threads in the same cluster. These threads are not synchronized with the thread running on different clusters.

This situation can be overcome by using SELECT FOR UPDATE query. SELECT FOR UPDATE query acquires exclusive row locks on the row(s) to be modified by the statement. Other transactions cannot view, update or delete the locked rows until the locking transaction either commits or rolls back.

synchronized (this) {
//Fetch a record from database.
//SELECT * FROM EMP_DETAILS WHERE STATUS=’not-verified’ FOR UPDATE.
//change the STATUS as ‘locked’ so that it is not visible to other threads.
//Commit / Rollback transaction to release the Lock.
}

By using SELECT FOR UPDATE, the row that is fetched from database is locked by oracle, irrespective of clustered or non-clustered environment. Once the STATUS is set to ‘locked’ for the given row, the lock can be released by committing (rollback) the transaction.

Note: Make sure that auto commit is set to false for this approach to work correctly.