3.1 Stubs and Skeletons

RMI uses a standard mechanism (employed in RPC systems) for communicating with remote objects: stubs and skeletons. A stub for a remote object acts as a client's local representative or proxy for the remote object. The caller invokes a method on the local stub which is responsible for carrying out the method call on the remote object. In RMI, a stub for a remote object implements the same set of remote interfaces that a remote object implements.

When a stub's method is invoked, it does the following:

• initiates a connection with the remote JVM containing the remote object,
• marshals (writes and transmits) the parameters to the remote JVM,
• waits for the result of the method invocation,
• unmarshals (reads) the return value or exception returned, and
• returns the value to the caller.

The stub hides the serialization of parameters and the network-level communication in order to present a simple invocation mechanism to the caller.

In the remote JVM, each remote object may have a corresponding skeleton (in Java 2 platform-only environments, skeletons are not required). The skeleton is responsible for dispatching the call to the actual remote object implementation. When a skeleton receives an incoming method invocation it does the following:

• unmarshals (reads) the parameters for the remote method,
• invokes the method on the actual remote object implementation, and
• marshals (writes and transmits) the result (return value or exception) to the caller.

In the Java 2 SDK, Standard Edition, v1.2 an additional stub protocol was introduced that eliminates the need for skeletons in Java 2 platform-only environments. Instead, generic code is used to carry out the duties performed by skeletons in JDK1.1. Stubs and skeletons are generated by the rmic compiler.

source: http://java.sun.com/j2se/1.4.2/docs/guide/rmi/spec/rmi-arch2.html

Singleton Patterns

Question
The Singleton pattern is not permitted by the J2EE spec, so How can I cache EJB home interfaces across EJBs in my application and avoid having each EJB get its own home interfaces?

Answer
This is one of those grey areas in the J2EE spec. Yes, it's true that theoretically, static objects (hence, singleton patterns) are not permitted. This is because you never know how many class loaders there are in your ejb container - unless you know the inner working of your container. Therefore, the singleton object will be unique in the class loader only. If there are multiple class loaders, your singleton object will exist more than once (1 instance per class loader). However, if you are ready to accept the fact that your ejb stub may be cached multiple times (as much as once in every class loader), the singleton pattern will still work.
Ithe ejb container's responsibility to cache ejb stubs. However, some implementation of jndi are very slow to lookup. Repeatedly performing jndi lookups can actually slow down your app considerably. In fact, I have written that exact singleton class you are contemplating and this has increased performance.

Thanks Nick Maiorano and Alex jguru-Jan 30, 2003

Using DateFormat/ Calendar

Using DateFormat:

import java.text.DateFormat;
Date date = DateFormat.getDateInstance(DateFormat.SHORT).parse("19/01/2006");
System.out.println(date);

Using calendar:

import java.util.Calendar;
new Date(Calendar.getInstance().getTimeInMillis())

simple...

Convert from java.util.Date to java.sql.Date

use the code like this:

java.util.date utilDate = new java.util.Date();
java.sql.Date sqlDate = new java.sql.Date(date.getTime());
System.out.println(sqlDate);

simple...

How To use a finder method returning more than one row in an ejb-ql?

1) write the ejb -ql in the EJB Deployment Descriptor as like:

method: findByObjectArray
ejb-ql: select object(o) from table_nm o where o.seq_id_fk = ?1

2) in the CMP Local interface, declare the finder fn:

public java.util.Collection findByObjectArray(java.lang.Integer SeqId) throws javax.ejb.FinderException;

Using the finder method:

3) call the finder method on local home. Initialise the iterator and use this iterator to access all the rows returned.

Collection newCollect = ejbLocalHm.findByObjectArray(seq_id);
Iterator iter = newCollect.iterator();

pretty simple for those who know...

Getting Primary Key Value (Custom Finder Method)

I created a session facade for my entity beans. In my entity beans apart from the findByPrimaryKey method I had a another finder method, based on another two attributes of the entity bean. Now the problem was how to get the value of the primary key, when i ran this finder method.

The solution:
Key seqKey = () ejbLocal.getPrimaryKey);
use: seqKey.

pretty simple for those who know...