Java_J2EE_Job_Interview_Companion

--------------Calculator with redo & undo operations---------------------------

Total = 10

Total = 5

Total = 15

Total = 13

---------------undo operation : 1 level---------------------------

Total = 15

---------------undo operation :2 levels---------------------------

Total = 5

Total = 10

---------------redo operation : 2 levels---------------------------

Total = 5

Total = 15

---------------redo operation : 1 level---------------------------

Total = 13

Scenario: The XYZ Retail has a 3rd party software component called XYZPriceList, which implements an interface PriceList. This 3rd party software component is not thread-safe. So far it performed a decent job since only the sales manager had access to this software component. The XYZ Retail now wants to provide read and write access to all the managers. The source code is not available and only the API is available, so modifying the existing component is not viable. This will cause a dirty read problem if two managers try to concurrently access this component. For example, if the sales manager tries to access an item’s price while the logistics manger is modifying the price (say modification takes 1 second), then the sales manager will be reading the wrong value. Let’s look at this with a code sample:

//transient value while updating with a proper value, just to illustrate the effect

//of concurrent access

mapPrices.put(new Integer(itemId),new Double(-1)); Thread.sleep(1000);//assume update/set operation takes 1 second mapPrices.put(new Integer(itemId),new Double(newPrice));

} catch (InterruptedException ie) {}

}

}

The multi-threaded access class:

public class PriceListUser implements Runnable {

int itemId; double price;

static int count = 0;

public PriceListUser(int itemId) { this.itemId = itemId;

}

/**

* runnable code where multi-threads are executed */

public void run() {

String name = Thread.currentThread().getName();

if (name.equals("accessor")) {

price = XYZPriceList.getInstance().getPrice(itemId); //using 3rd party commponent

} else if (name.equals("mutator")) {

XYZPriceList.getInstance().setPrice(itemId, 15.00); //using 3rd party commponent

}

}

}

Now, let’s see the calling code or class Shopping:

//....

public class Shopping {

//....

public static void process() throws ItemException {

PriceListUser user1 = new PriceListUser(1);//accessing same itemId=1

PriceListUser user2 = new PriceListUser(1);//accessing same itemId=1

Thread t1 = new Thread(user1);

Thread t2 = new Thread(user2);

Thread t3 = new Thread(user1);

t1.setName("accessor");//user 1 reads the price t2.setName("mutator");//user 2 modifies the price t3.setName("accessor");//user 1 reads the price

t1.start(); // accessor user-1 reads before mutator user-2 modifies the price as 12.00 t2.start(); // mutator user-2 sets the price to 15.00

t3.start(); // while the user-2 is setting the price to 15.00 user-1 reads again and gets the // price as 12.00

//user-2 gets the wrong price i.e gets 12.0 again instead of 15.00

}

}

The output is:

---------------Accessing the price list---------------------------

The price of the itemId 1 = 12.0

wait while mutating price from 12.0 to 15.00 ...........

The price of the itemId 1 = -1.0

OR

---------------Accessing the price list---------------------------

wait while mutating price from 12.0 to 15.00 ...........

The price of the itemId 1 = -1.0 The price of the itemId 1 = -1.0

Problem: You get one of the two outputs shown above depending on how the threads initialized by the operating system. The first value of 12.0 is okay and the second value of 12.0 again is a dirty read because the value should have been modified to 15.0 by the user-2. So the user-1 reading the value for the second time should get the value of 15.0 after it has been modified.

}

public void setPrice(int itemId, double newPrice) { synchronized (locks[itemId]) {

realPriceList.setPrice(itemId, newPrice);

}

}

}

«interface»

PriceList

+getPrice()

+setPrice()

You should make a slight modification to the PriceListUser class as shown below in bold.

public class PriceListUser implements Runnable {

int itemId; double price;

static int count = 0;

public PriceListUser(int itemId) { this.itemId = itemId;

}

/**

* runnable code where multi-threads are executed */

public void run() {

String name = Thread.currentThread().getName();

if (name.equals("accessor")) {

price = XYZPriceListProxy.getInstance().getPrice(itemId);

} else if (name.equals("mutator")) { XYZPriceListProxy.getInstance().setPrice(itemId, 15.00);

}

}

}

Running the same calling code Shopping will render the following correct results by preventing dirty reads:

---------------Accessing the price list---------------------------

What is a dynamic proxy? Dynamic proxies were introduced in J2SE 1.3, and provide an alternate dynamic mechanism for implementing many common design patterns like Façade, Bridge, Decorator, Proxy (remote proxy and virtual proxy), and Adapter. While all of these patterns can be written using ordinary classes instead of dynamic proxies, in many situations dynamic proxies are more compact and can eliminate the need for a lot of handwritten classes. Dynamic proxies are reflection-based and allow you to intercept method calls so that you can interpose additional behavior between a class caller and its callee. Dynamic proxies are not always appropriate because this code simplification comes at a performance cost due to reflection overhead. Dynamic proxies illustrate the basics of Aspect Oriented Programming (AOP) which complements your Object Oriented Programming. Refer Q03, Q04 and Q05 in Emerging Technologies/Frameworks section.

Where can you use dynamic proxies? Dynamic proxies can be used to add crosscutting concerns like logging, performance metrics, memory logging, retry semantics, test stubs, caching etc. Let’s look at an example:

InvocationHandler interface is the heart of a proxy mechanism.

import java.lang.reflect.InvocationHandler;

import java.lang.reflect.InvocationTargetException; import java.lang.reflect.Method;

/**

* Handles logging and invocation of target method */

public class LoggingHandler implements InvocationHandler {

protected Object actual;

public LoggingHandler(Object actual) { this.actual = actual;

}

public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { try {

System.out.println(">>>>>>start executing method: " + method.getName()); Object result = method.invoke(actual, args);

return result;

} catch (InvocationTargetException ite) {

throw new RuntimeException(ite.getMessage()); } finally {

System.out.println("<<<<<<finished executing method: " + method.getName());

}

}

}

Let’s define the actual interface and the implementation class which adds up two integers.

public interface Calculator {

public int add(int i1, int i2);

}

public class CalculatorImpl implements Calculator {

public int add(int i1, int i2) { final int sum = i1 + i2;

System.out.println("Sum is : " + sum); return sum;

}

}

Factory method class CalculatorFactory, which uses the dynamic proxies when logging, is required.

import java.lang.reflect.InvocationHandler; import java.lang.reflect.Proxy;

/**

* singleton factory */

public class CalculatorFactory {

private static CalculatorFactory singleInstance = null; private CalculatorFactory() {}

public static CalculatorFactory getInstance() {

if (singleInstance == null) {

singleInstance = new CalculatorFactory();

}

return singleInstance;

}

public Calculator getCalculator(boolean withLogging) { Calculator c = new CalculatorImpl();

//use dynamic proxy if logging is required, which logs your method calls if (withLogging) {

//invoke the handler, which logs and invokes the target method on the Calculator

InvocationHandler handler = new LoggingHandler(c);

//create a proxy

c = (Calculator) Proxy.newProxyInstance(c.getClass().getClassLoader(), c.getClass().getInterfaces(), handler);

}

return c;

}

}

Finally the test class:

import java.lang.reflect.InvocationHandler; import java.lang.reflect.Proxy;

public class TestProxy {

public static void main(String[] args) {

System.out.println("==============Without dynamic proxy============="); Calculator calc = CalculatorFactory.getInstance().getCalculator(false); calc.add(3, 2);

System.out.println("===============With dynamic proxy================"); calc = CalculatorFactory.getInstance().getCalculator(true);

calc.add(3, 2);

}

}

The output is:

==============Without dynamic proxy============= Sum is : 5

===============With dynamic proxy================

>>>>>>start executing method: add Sum is : 5

<<<<<<finished executing method: add

Useful links:

http://www.allapplabs.com/Java_design_patterns/creational_patterns.htm

http://www.patterndepot.com/put/8/JavaPatterns.htm

http://www.javaworld.com/columns/jw-Java-design-patterns-index.shtml

http://www.onjava.com/pub/a/onjava/2002/01/16/patterns.html?page=1

http://www.corej2eepatterns.com/index.htm

http://www.theserverside.com/books/wiley/EJBDesignPatterns/index.tss

View Helper: When processing logic is embedded inside the controller or view it causes code duplication in all the pages. This causes maintenance problems, as any change to piece of logic has to be done in all the views. In the view helper pattern the view delegates its processing responsibilities to its helper classes. Refer Q25 in Enterprise section.

Service to Worker and Dispatcher View: Refer Q25 in Enterprise section.

B Æ Use a Business Delegate design pattern to reduce the coupling between the presentation tier components and the business services tier components. Refer Q83 in Enterprise sections.

C Æ The JNDI look-up is expensive because the client needs to get a network connection to the server first. So this lookup process is expensive and redundant. To avoid this expensive and redundant process, service objects can be cached when a client performs the JNDI look-up for the first time and reuse that service object from the cache for the subsequent look-ups. The service locator pattern implements this technique. Refer Q87 in Enterprise section.

D Æ EJBs use proxy (Refer Q62 in Java section) design pattern. Avoid fine-grained method calls by creating a value object (Refer Q85 in Enterprise section) design pattern, which will help the client, make a coarse-grained call. Also use a session façade (Refer Q84 in Enterprise section) design pattern to minimize network overheads and complexities between the client server interactions. For faster data access for read-only data of large resultsets use a fast-lane reader (Refer Q86 in Enterprise section) design pattern.

D, E, F Æ Use factory pattern to reduce the coupling or the dependencies between the calling code (e.g. EJB etc) and called code like business objects, handler objects, data access objects etc. This is a very powerful and common feature in many frameworks. Refer Q52 in Java section. When writing your factory class, it does not make sense to create a new factory object for each invocation. So use a singleton design pattern to have a single instance of the factory class per JVM per class loader. Refer Q51 in Java section.

F Æ Use the data access object design pattern to promote the design concept of code to interface not implementation, so that the implementation can change without affecting the calling code.

Q 13: How would you go about determining the enterprise security requirements for your Java/J2EE application? A 13: It really pays to understand basic security terminology and J2EE security features. Let’s look at them:

Some of the key security concepts are:

Authentication

Authorization (J2EE declarative & programmatic)

Data Integrity

Confidentiality and privacy

Non-repudiation and auditing