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