<vendor>
Our implementation is quite similar to Sybase's, meaning we use dynamic
class-loaders to load or reload new interfaces and/or bean implementations
into a running container. This enables us to simultaneously run multiple
versions of a given EJB, or to on-the-fly upgrade EJBs (giving "24x7x52",
not "24x7x365": why do people want systems to stay up for seven years ;-)
For details, you might want to look at the clustering white paper at:
http://www.borland.com/appserver/papers/
</vendor>
-jkw
Dave Wolf wrote:
>
> <vendor>
>
> Sybase EAServer handles this by
>
> 1) If a client is actively using an object, stateful or stateless when a hot
> refresh occurs that clients instance is left intact.
> 2) All instances in the pool are flushed and replaced with the new
> implementation
>
> The client receives no Exception. As Cedric puts it, we silently redirect
> new calls to the new versions of the implementations. We consider this an
> HA requirement. Who wants to fill yuoru client with tons of catch/retries
> for when a refresh might happen. You need HA for both unplanned as well as
> planned maintenance. As Cedris says, this is accomplished through the use
> of ClassLoaders in Sybase EAServer as well. We also provide a mechanism to
> conrtol which classes are loaded by which Classloader. In this way you can
> control exactly what classes are refreshed when a refresh is requested.
> This applies to EJB's, WAR's etc. Refreshes are allowed at the server,
> Application or Component level.
>
> </vendor>
>
> Dave Wolf
> Internet Applicastions Division
> Sybase
>
> > > 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".
> >
> >
>
> ===========================================================================
> 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".
