I would still *strongly* discourage anyone from persisting longlived
references to EJBs that cannot be easily created. Even if the EJB vendor
does a good job with their implementation of serialized handles so that they
are independent of host, port, etc., you don't want to end up vendor
specific serialized handles persisted all over your system. You're data is
not portable to other vendors and you're at the mercy of your current vendor
not to make incompatible changes to how the mechanism works.
Jeff Bailey ([EMAIL PROTECTED])
Sr. Software Engineer
NetGenics, Inc.
-----Original Message-----
From: John O'Shea [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 20, 1999 8:59 AM
To: [EMAIL PROTECTED]
Subject: Re: Q: is EJBHandle fragile?
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".
===========================================================================
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".
