Hey
John O'Shea wrote:
> > 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)
Well, let's just say that theory and practice in this case are two quite
different beasts :-)
Specifically, if handles between beans are done by storing Handle's,
then you will not be able to move to another EJB server without breaking
your entire object graph, as the handles will not be valid within the
new EJB server. And that's just the way it is.
Also, it is my experience that as EJB servers get upgraded the Handle
implementation may not be compatible with older versions, so any attempt
to load them will yield serialization errors.
The fool-proof way to go is to store primary keys yourself. Maximum
control, hardly any drawbacks (if done(/abstracted) right).
> 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.
The term "should" has different meanings in theory and practice. ;-)
> 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.
See above re: "should"
> 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."
The only way to implement this (AFAIK) is to include host information in
the handle. Which will break your system should you decide to move it.
This discussion is about a year old. I suggest that you check the
archives for lots and lots of arguments (I can't remember the thread
name right now though).
> 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.
Until someone proves me wrong, I would not follow these guidelines. Call
me paranoid if you will...
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
Homepage: http://www-und.ida.liu.se/~ricob684
===========================================================================
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".
