Design Patterns and Java Internals

[Ans] This is a debatable question, and for every answer we propose there can be contradictions. I propose 2 solutions fo the same. Remember that EJB's are distributed componenets and can be deployed on different JVM's in a Distributed environment

i) Follow the steps as given below

• Make sure that your serviceLocator is deployed on only one JVM.
• In the serviceLocator create a HashTable/HashMap(You are the right judge to choose between these two)
• When ever a request comes for an EJB to a serviceLocator, it first checks in the HashTable if an entry already exists in the table with key being the JNDI name of EJB. If key is present and value is not null, return the existing reference, else lookup the EJB in JNDI as we do normally and add an entry into the Hashtable before returning it to the client. This makes sure that you maintain a singleton of EJB.

ii) In distributed environment our components/Java Objects would be running on different JVM's. So the normal singleton code we write for maintaining single instance works fine for single JVM, but when the class could be loaded in multiple JVM's and Instantiated in multiple JVM's normal singleton code does not work. This is because the ClassLoaders being used in the different JVM's are different from each other and there is no defined mechanism to check and compare what is loaded in another JVM. A solution could be(Not tested yet. Need your feedback on this) to write our own ClassLoader and pass this classLoader as argument, whenever we are creating a new Instance and make sure that only one instance is created for the proposed class.This can be done easily.

[Ans] When Synchronization is applied on a static Member or a static block, the lock is performed on the Class and not on the Object, while in the case of a Non-static block/member, lock is applied on the Object and not on class. [Trail 2: There is a class called Class in Java whose object is associated with the object(s) of your class. All the static members declared in your class will have reference in this class(Class). As long as your class exists in memory this object of Class is also present. Thats how even if you create multiple objects of your class only one Class object is present and all your objects are linked to this Class object. Even though one of your object is GCed after some time, this object of Class is not GCed untill all the objects associated with it are GCed.

This means that when ever you call a "static synchronized" block, JVM locks access to this Class object and not any of your objects. Your client can till access the non-static members of your objects.

I think this should give a detailed explaination of the question. If you guys feel this is too abstract or too complex explanation. Do let me know.]

[Ans] Any global members(Variables, methods etc.) which are static are called as Class level members and those which are non-static are called as Instance level members.

[Ans] Here they go:

• Mark and Sweep
• Reference counting
• Tracing collectors
• Copying collectors
• Heap compaction
• Mark-compact collectors

[Ans] Its uses Reference while manipulating objects but pass by value when sending method arguments. Those who feel why I added this simple question in this section while claiming to be maintaining only strong and interesting questions, go ahead and answer following questions.

a)What is the out put of:

		
import java.util.*;

class TestCallByRefWithObject 
{
	ArrayList list = new ArrayList(5);
	

	public void remove(int index){
		list.remove(index);
	}

	public void add(Object obj){
		list.add(obj);
	}

	public void display(){
		System.out.println(list);
	}
	
	public static void main(String[] args) 
	{
		TestCallByRefWithObject test = new TestCallByRefWithObject();
	
		test.add("1");
		test.add("2");
		test.add("3");
		test.add("4");
		test.add("5");

		test.remove(4);
		test.display();
	}
}
		

b) And now what is the output of:

import java.util.*;

class TestCallByRefWithInt
{
	int i = 5;
	

	public void decrement(int i){
		i--;
	}

	public void increment(int i){
		i++;
	}

	public void display(){
		System.out.println("\nValue of i is : " +i);
	}
	
	public static void main(String[] args) 
	{
		TestCallByRefWithInt test = new TestCallByRefWithInt();
	
		test.increment(test.i);

		test.display();
	}
}

• http://mindprod.com/jgloss/callbyreference.html (My favorite ready reckoner)
• http://www.javaworld.com/javaqa/2000-05/03-qa-0526-pass_p.html

[Ans] A thread is never faster than a process. If you run a thread(say there's a process which has spawned only one thread) in one JVM and a process in another and that both of them require same resources then both of them would take same time to execute. But, when a program/Application is thread based(remember here there will be multiple threads running for a single process) then definetly a thread based appliation/program is faster than a process based application. This is because, when ever a process requires or waits for a resource CPU takes it out of the critical section and allocates the mutex to another process.

Before deallocating the ealier one, it stores the context(till what state did it execute that process) in registers. Now if this deallocated process has to come back and execute as it has got the resource for which it was waiting, then it can't go into critical section directly. CPU asks that process to follow scheduling algorithm. So this process has to wait again for its turn. While in the case of thread based application, the application is still with CPU only that thread which requires some resource goes out, but its co threads(of same process/apllication) are still in the critical section. Hence it directly comes back to the CPU and does not wait outside. Hence an application which is thread based is faster than an application which is process based.

Be sure that its not the competion between thread and process, its between an application which is thread based or process based.

[Ans] Design Patterns are the proposed solutions for the commonly occuring problems in a given context.