In our initial implementation we implemented extensive caching of the
InitialContext, as well as references to various <ejb-ref> mappings in the
contexts, however, we have since reverted on this decision and are not
attempting to cache IntialContext or any <ejb-ref> lookups, here is why:
The point of reference where you decide to create new InitalContext() could
determine the values placed into the initial context. Thus if you continue
to re-use the same initial context you will get wrong values. Suppose there
is a bean A with an <ejb-ref>ref1</ejb-ref> in it's environment, and beam B
with <ejb-ref->ref1</ejb-ref> in it's environment. In both cases, ref1
could point to the same home, same interface, but DIFFERENT implementations
(using different link values). Thus when bean A does a lookup for ref1 from
a new InitialContext, it will get a value "different" from when Bean B does
a similar lookup.
The same problem could result in trying to cache lookups to <ejb-ref> from
different beans in some global "static" area. From the point of view of
bean A, ref1 is a completely different animal than from the point of view of
bean B. Thus a lookup for ref1 from B would not produce the same value from
A, thus you cannot effectively cache the values.
-AP_
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Gene Chuang
Sent: Monday, July 30, 2001 11:13 AM
To: [EMAIL PROTECTED]
Subject: Re: Caching, optimization, need opinions.
As many have said, client stub fail-over and round-robining is implemented
differently by different vendors. For example, BEA does it at the
EJBHome/EJBObject level while Borland does it at InitialContext level.
Hence to make your codes fail-over-portable, you will need to cache at both
levels!
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.
Gene Chuang
Kiko.com
-----Original Message-----
From: Maxime Poulin [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 30, 2001 8:06 AM
To: [EMAIL PROTECTED]
Subject: Caching, optimization, need opinions.
Hi all !
I have some questions regarding caching and optimisation, and some code
style...
Here is the description, it is a very standard client-ejb program. We
have the JSPs and servlets which are accessed by the clients to perform
queries. The queries are passed to our API, which in turn connect to the EJB
server where all the business logic is performed.
Which means that it is in my API objects that I access the beans. When I
first started the project, I didn't have a lot of knowledge on EJBs but now
I am going back to that code for some cleanups and some questions popped to
me.
Regarding caching :
Creating an initial context might take some time and when I coded my
API objects, I decided to cache the initial context. This way, I didn't have
to recreate it each time, thus saving some cycles. But is this really a good
idea ? Like suppose I have 2 containers, C1 and C2. I create an initial
context and access a bean on C1. If a few minutes later C1 fails, will my
bean calls still work ? I mean, is my InitialContext bound to a specific EJB
Container or is it dynamic ? So is it a good idea to cache the initial
context (so it is used by all my API objects) ?
If I should not cache the initial context, would it be a better idea
to cache the home interface to my beans ?
So simply put, should I cache the context, the home interface or
anything or just let the system do its magical work all by itself ?
Maxime.
===========================================================================
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".
