Hi Rickard,
Rickard �berg wrote:
>
> Well, let's just say that theory and practice in this case are two quite
> different beasts :-)
Perhaps. Maybe you should get on to Sun to specify that all handles be
transient in nature :-) I don't agree though. Maybe someone from
Javasoft can contribute to this debate and clarify?
> 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.
Again, I come back to my point that this is a container implementation
issue - you are assuming that no EJB container can support this
functionality. However, CORBA based EJB servers (one springs to mind :)
can support transparent dynamic POA (read "EJB") relocation from one
server process to another at runtime - client requests are redirected to
the new server process by using GIOP's LOCATION_FORWARD reply status
(remember, RMI runs over IIOP now). This can be done by either the old
EJB server process or a domain wide location daemon. The client never
knows the EJB has moved and the handle remains valid.
I am, of course, talking about relocating containers to another server
from the same vendor. You may argue that this isn't 'complete' enough
but this capability is extremely powerful - for example, it aids server
cluster load balancing and fault tolerance. Transparently relocating
EJBs from one vendors server to another may become possibly if handles
formats are ever formalized.
> 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.
A single vendor should be careful enough when defining EJB handle
formats to make sure they are extensibile. Moving EJBs from one vendor's
to another's server is a different issue and would obviously require
that older handles become invalid since EJB handle formats are not
standardized by the EJB 1.1 specification.
> The fool-proof way to go is to store primary keys yourself. Maximum
> control, hardly any drawbacks (if done(/abstracted) right).
Unfortunately your client becomes more complicated and will generate
more network traffic/load on core services. It will always need to be
prepared to JNDI lookup the Home interface, re-find the EJB, and then
re-invoke on any invocation when this may not be necessary. For high
end systems, optimizing such overheads can lead to significant
performance gains.
<snip>
> > 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.
It is possible (and implemented) although I'd hate to go into it in
detail here since it's quite CORBA-centric.
> 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).
Perhaps this discussion is about a year old but advancements have been
made in the interim. IIOP has become the underlying protocol for RMI
thereby opening up the use of CORBA's rich distrbution mechanisms. RMI
over JRMP never had such capabilities. Couple that with EJB container's
built on the ORBs which use the latest features of CORBA 2.3
(specifically POAs) and all of the above is possible. I'm not vendor
plugging here - you need to look no further than Sun's own J2EE
reference implementation to find a CORBA based EJB server.
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".
