Gene, what do you mean by
"
> if your servlet does a EJBHome
> lookup for each service() call, you will find your web layer "bound" to
the
> first node of your app cluster! And I assume the analogous behavior for
> Borland if you reconstruct InitialContext each time...
"
----- Original Message -----
From: "Gene Chuang" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 31, 2001 2:48 PM
Subject: Re: Caching, optimization, need opinions.
> Let me bring another issue into the picture: cluster round-robining.
>
> Like I said previously, different vendors implement this at different
> levels. For example, Weblogic implements cluster round-robining at
EJBHome,
> while Borland App Server implements this at InitialContext.
>
> What this means, then, is if you do not reuse a client stub at the
> respective level of cluster-replica implementation, you will NOT see
> round-robining! For example, under Weblogic, if your servlet does a
EJBHome
> lookup for each service() call, you will find your web layer "bound" to
the
> first node of your app cluster! And I assume the analogous behavior for
> Borland if you reconstruct InitialContext each time...
>
> This is a prime example of the J2EE spec not specifying clearly a
particular
> important behavior, thus causing headaches for both app developers
> andvendors.
>
> Gene Chuang
> Kiko.com
>
>
> -----Original Message-----
> From: Maxime Poulin [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, July 31, 2001 7:41 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Caching, optimization, need opinions.
>
>
> So ! Seems like this subject is even more opened than what I thought when
> posted my question...
>
> So, if I may recap :
> - Strategy 1 :
> Just don't cache. When a been is needed, just get a new
> InitialContext(...), lookup the home, narrow it, get the remote and
that'it.
> + Advantages :
> 1.Well, optimization should be done by the vendor, so this technique
> clears my code a bit, and leaves the responsibility to the vendor. For
what
> I've seen, WebSphere and Inprise are doing their job on this.
> 2. ?
> + Disadvantages :
> 1. Some vendors might not have done their job, so creating the context
> or looking up a name might always take some time.
> If a lot of bean access is done, a lot of objects will be created over
> and over again.
> 2. ?
>
> - Strategy 2 :
> Cache the initial context.
> + Advandatages :
> 1. Do not have to recreate over and over...
> 2. ?
> + Disadvantages :
> 1. A lot of question marks :
> - What happens if a container fails ? Can that context be reset ?
> 2. ?
>
> - Strategy 3 :
> Cache the home
> + Advantages :
> 1. No need to cache to use the initial context once all home
interfaces
> are cached.
> 2. Fastest possibility in my point of view
> + Disadvantages :
> 1. ?
>
> - Strategy 4 :
> Cache the remote
> + Advantages :
> 1.Well, nothing to create !
> 2. ?
> + Disadvantages :
> 1. Well, I guess that this would only work with stateless session
> beans...
> 2. ?
>
> - Strategy 5 :
> A wrapper containing access methods to the context and home
interfaces,
> if an exception is encountered, recreate the context and homes. Can be
> disabled/partially enabled/enabled easily depending on the vendor with a
> config file.
> + Advantages
> 1. Flexible - Adapts to different situation.
> 2. In "enabled" mode, exceptiopn handling gives us some insurance...
If
> a problem occurs, the context is recreated, same for interfaces.
> 3 ?
> + Disadvantages :
> 1. Questions : You make that class a singleton ? Everything is static
?
> 2. ?
>
> This is my recapitulation version 1 :) I just took some ideas here and
there
> from this thread.... However, I am not very confortable with concurrency
yet
> so I didn't say much about sync and thr-safe.
>
>
>
> ----- Original Message -----
> From: "Avi Kivity" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, July 31, 2001 3:04 AM
> Subject: Re: Caching, optimization, need opinions.
>
>
> > > Using DynamicProxy, I've written an abstract FailOverEJBHome
> > > stub that wraps
> > > both EJBHome and InitialContext for this exact purpose. This
> > > is the best
> > > way to ensure your architecture is clusterable across any app server.
> > >
> > I've done something similar, and I can't help feeling disgusted at the
> > vendors. Isn't that their job? Yuck. Each non-business-logic line of
code
> > points at a hole either in the spec or in the implementation.
> >
> > - Avi
> > --
> > This signature intentionally left blank.
> >
> >
>
===========================================================================
> > 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".
