Hi Rickard,

>
> So, in other words: don't use handles as longlived references to beans.

The spec seems to contradict this.  Sect 8.7 - "An entity handle is
typically implemented to be usable over a long period of time � it must
be usable at least across a server restarts."
There is no explicit references to the validity of session handles and
home handles across server restarts but other sections of the spec which
focus on the client's use of handles seems to presume that all handles
are long lived. (see quotes below)

> Even within the scope of the handle implementation they are not a good
> idea to use as it is not specified whether or not it should include the
> name of the EJB server which the object lives on. If it is included your
> entire database will break if you move your system to another machine
> (unless you move the DNS name to the new server at the same time!).

How handles are implemented is a container implementation issue.  A
decent container implementation can create EJB Handles which are
independent of the container process, port number and host name.  A more
restrictive container implementation would encode location specific info
directly into the handle and therefore constrain that container's EJBs
to execution in that location only.
Ideally, containers should be able to transparently shut down and
relocate to a different server (and host if necessary) without
invalidating already-exported EJBHandles.  This is most useful for
Entity bean handles and all types of Home handles.

There are several references in the specification which indicate that a
client can serialize a handle and at some later stage deserialize the
handle and re-use it.  The presumption seems to be that the handle
remains valid.  This all suggests to me that EJB containers should
support long lived EJB Handles.

References from EJB 1.1 (Public Release):

Section 5.3 "Obtain a handle for the home interface. The home handle can
be serialized and written to stable
storage. Later, possibly in a different JVM, the handle can be
deserialized from stable storage
and used to obtain back a reference of the home interface."

Section 8.7 "Since a handle class extends java.io.Serializable, a client
may serialize the handle. The client
may use the serialized handle later, possibly in a different process or
even system, to re-obtain a reference
to the entity object identified by the handle."

Section 8.8 "The EJB specification allows the client to obtain a handle
for the home interface. The client can use the home handle to store a
reference to an entity bean�s home interface in stable storage, and
re-create the reference later. This handle functionality may be useful
to a client that needs to use the home interface
in the future, but does not know the JNDI name of the home interface.

j.

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

Reply via email to