>>>> not "24x7x365": why do people want systems to stay up for seven years ;-)

24x7x365 is all year nonstop, not 7 years ( 24 hours 7 days 365 days a year)  :-p

-----Original Message-----
From: Jonathan K. Weedon [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 02, 2000 12:39 PM
To: [EMAIL PROTECTED]
Subject: Re: availability during redeployment of an EJB.


<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".

===========================================================================
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".

Reply via email to