Hi Alex,
> The point of reference where you decide to create new InitalContext()
could determine the values placed into the initial context.
Which app server are you using? Because the way I understand it, the
Environment Naming Context local to a bean is completely INDEPENDENT of the
InitialContext instance. Rather, the ENC is ThreadLocal to the bean
instance, just like ACL and Principle info. At least this is the behavior I
get on Weblogic 5.1.
In our architecture, we have EJBs A, B, C. But they all extend
AbstractEJBean (look at my pattern on theserverside.com
http://www.theserverside.com/patterns/thread.jsp?thread_id=7270), which
contains a static reference to InitialContext: i.e. all instances of A, B
and C use the same InitialContext. However, they do have different ENC
values of the same key, and in runtime they do resolve to their appropriate
values!
Gene
-----Original Message-----
From: Alex Paransky
To: [EMAIL PROTECTED]
Sent: 7/30/01 6:58 PM
Subject: Re: Caching, optimization, need opinions.
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".
===========================================================================
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".
