> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Richard Landon
> How can redployment work within the context of a single Java VM J2EE
> architecture?
Very carefully ;-)
> Once the VM loads a class file (or a bunch-o-class files, aka, a jar) then
> it can't "unload" a class file can it? Thus doesn't the single VM have to go
down
> (resulting in a loss of service)?
No, you simply create a new classloader to load the new classes. The old ones
will eventually be garbage collected with their (now unused) classloader.
> Also, if one redeploys, say a stateless session bean, that has been used,
> then how does it get evicted from memory, without a JVM shutdown? Can J2EE
servers
> redploy with clients accessing the EJB being re-deployed, or do you have to
kick out
> the clients off the system when you redeploy (forget 24x7x365)?
These are the real tricky issues and I don't think there is a standard way of
proceeding. Some elements of response:
- clients holding stubs to remote objects should receive a
NoSuchObjectException (being silently redirected to a new instance is probably
not the best idea, but a point can be made for that as well)
- the real problem lies in in-flight transactions. You can choose to rollback
them all right away (the easy way) or wait for them to time out. It all
depends how sophisticated you want your deployment to be
There are also several possible scenarios to make the new homes available to
existing clients.
--
Cedric
===========================================================================
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".
