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