Singleton is not really a singleton?

Singleton design pattern is one of the oldest pattern which I learn in college. People like me who have migrated to java world from C++ world finds it hard to digest that if we are not very clear, there can be cases when a singleton java class can have more than one instance. There could be multiple reason for this, details can be found under "Sun Developer Site". One of the reason which C++ people might find difficult is that - if one application uses two different class loaders, then you will get two instances of the singleton class (Each class loader represents one unique namespace, so two classes even if they are the same, if gets loaded by two different class loaders, become two distinct instances). If we think about it in Servlet world, the Servlet container decides when to load the singleton class and when to destroy it. If we are not very clear about the way servlet engine is loading the servlet classes, we might end up having two different instances of the singleton class.

Httpsession Vs Stateful Session Bean

This is an interesting topic and many people have talked about it and wrote in internet. As far as I understood is that - httpsession is an wonderful mechanism to track client's state (you can even get the callback functionality through HttpSessionBindingListener), its easy to use and faster to implement. Whereas Stateful session bean comes with some overhead (its known that Stateful Session beans are heavier than Stateless session bean, though I think newer EJB specifications are going to change those perceptions), httpsession is much an immediate solution.
Think of the use case that if all the clients of your business layer are coming through WEB, its safer to implement stateful-ness through httpsession. But what if there are other clients as well - like Plain Java Swing based clients, WAP enabled phones etc are also your client of the business layer and then it makes clear sense to adopt Stateful Session bean rather than tracking states through Stateful session beans.

Tracking states through httpsession is a presentation layer trick , whereas tracking states through session beans is a business layer trick. If we keep this in mind it will be easier for us to choose one or the other depending our use-case.

Java's Synchronization support may lead to read/write performance bottlenecks

In order to support multi-threading applications, Java provides "synchronized" keyword. The problem with Java's basic support of synchronization is that - synchronized keyword locks on the object level. For example, if we mark one method of a class as synchronized, then if one thread is inside this method, no other thread can not run any synchronized code of the same object.
lets take an example of a Cache implementation. Lets say we created one hashtable which is the cahche in our application. It caches some objects which are otherwise to be fetched from the database. In order to save the round-trip, some of the objects are read from the database and are cached inside the hashtable. Now as it is a cache, so there will be more reads than writes. If we use synchronized keyword and use the cache object as synchronized object, all reads and writes to this cache will be serialized. Whereas in reality, multiple reads can happen concurrently and can enhance performance.

For a minute, lets think about a database table, most of the time we read from the table and at times we write into the table. If reads are serialized, the whole application will become slower. So database have concept like "shared lock" and "exclusive lock".

Sometimes it become very obvious in case of Java applications also to adopt to this type of "shared lock" and "exclusive lock". Reads from the cache should hold a shared lock and write to it should hold an exclusive lock.

Since Java's native API does not support this one needs to write his own logic to make sure he is following this shared/exclusvie concepts.

Here comes this book which is very handy - "Concurrent Programming in Java: Design Principals and Practices". The author Doug Lea maintains a site http://gee.cs.oswego.edu/dl/ where he has a package called util.concurrent which can perform lot of such locking. These packages are also getting included in JSR166.

EJB3 does not have EJBHandle

People who have worked extensively on EJB2, might have used EJBHandle. According to EJB specifications, when we use EJB2.1 and get the EJB stub from the EJB home interface, this stub can not be serialized. Hence in case of a stateful session bean, if you want to store the handle to the particular session bean, you can get the handle of the bean and store the handle by serializing it. Later you can de-serialize it and can connect to the same bean and go back to the same state. This was particularly useful in case of "Failover scenarios" or in case of advanced spftwares where we can provide resume later kind of option. So you save the state to your disk, come back later and get hooked to the same state. (Think of accessing one Stateful session bean from servlet and you want to store the handle in the Httpsession to make sure any browser refresh or so can get you back to the same session bean always)

This is being modified in EJB3, EJB 3 actually does not support EJB Handle. It was tough for me to digest this fact for some time till I realized that in case of EJB 3, the proxy object that the container provides when we look up the bean using context or by using "dependency injection", is serializable. So the proxy object that we get from the context can be serialized and later de-serialized to connect to the same Stateful session bean. This eliminates the need to EJBHandle altogether.

EJBHome and EJBObject are missing in EJB3.0

Programmers when migrate from EJB 2 to EJB 3, get their first doubt around the fact that EJB 3 does not need any HOME interface or EJBObject interface.
Why does EJB 3 do not need these interfaces ?

Home interface is nothing but serves as a "factory" for creating references to the remote EJB Object. Home interface was same for stateless session beans and message driven beans as they are initialized in a similar way. In case of stateful session bean, the home interface used to take an argument which used to take parameters to initialized the states. This is a programming practice and in case of EJB 3, you achieve the same thing by "setting the states" on the bean using some setter methods. Thus we can actually remove the home interface all together and get the handle of the remote business interface directly as we do in case of EJB3.

EJBobject interface was required to provide a client view of the EJB. Container used to provide implementation of this interface and container used this EJBObject interface as a nice hook for invoking container provided services like transaction, security etc. Fortunately the EJB containters in EJB 3 have made this more behind the scene and they actually do not depend upon an extra interface , rather they implement the Business interface and provide the same container services between the business interfaces and the bean object.