Is it OK to cache home stubs in 6.1?

I heard that caching home stubs may cause hot deployment issues in WebLogic
server. Is this the case for 6.1? What about remote stubs (i.e. for a
stateless session bean)?
Thanks,
Bob

Regarding the remotes stubs: Remote interface is not serializable. If your app
needs to work in clustered env then weblogic 6.1 will have problems replicating
the remote interface. If you absolutely have to cache the remote stub in httpsession,
get the handle of the remote interface and cache it. To get the remote interface
from the handle use handle.getEJBObject().
sudy
"Bob Lee" <[email protected]> wrote:
I heard that caching home stubs may cause hot deployment issues in WebLogic
server. Is this the case for 6.1? What about remote stubs (i.e. for a
stateless session bean)?
Thanks,
Bob

Similar Messages

Servlet - EJB, caching home & context problem

Hello,
I just run into the following problem:
I created a thin client which accesses the EJB's via a servlet.
In this servlet I cached the InitialContext und and the reference
to the Home interface. While creating the initial context I provided
login/password to access the EJB so it can't be accessed from the guest
user.
The first method call works as expected, any further call results
in a RemoteException - Insufficent permissions.
Any hints? I'm using 5.1, SP6.
Zhanxs in advance
Marcel

The security creditials you suppplied to the IntialContext are only applied
to the thread that created the InitialContext. I have only found one
work-around - Construct an otherwise useless IntialContext each time a
thread attempts to use and EJB or its home. This is inefficient and almost
(not quite) destroys the advantage of caching the stubs.
Is there any other solution? Any thing coming down the pike?
Chuck McCorvey
"Marcel Zielinski" <[email protected]> wrote in message
news:[email protected]..
Hello,
I just run into the following problem:
I created a thin client which accesses the EJB's via a servlet.
In this servlet I cached the InitialContext und and the reference
to the Home interface. While creating the initial context I provided
login/password to access the EJB so it can't be accessed from the guest
user.
The first method call works as expected, any further call results
in a RemoteException - Insufficent permissions.
Any hints? I'm using 5.1, SP6.
Zhanxs in advance
Marcel

EJB home stubs in a cluster

The following URL describes how replica-aware EJB home stubs work. Basically,
when you do a lookup for the EJB home in JNDI, you get a home stub on any of the
nodes in the cluster.
However, I want to invoke EJBs on a particular node in the cluster. Can I do
this by simply disabling the replica-aware EJB home in the deployment descriptor
and doing a remote JNDI lookup on the desired node in the cluster? And if so,
would I have to bind each EJB's home to JNDI with a different name?
-reza
http://edocs.bea.com/wls/docs61/cluster/object.html#1006777
All bean homes can be clustered. When a bean is deployed on a server, its home
is bound into the cluster-wide naming service.
Because homes can be clustered, each server can bind an instance of the home under
the same name. When a client looks up this home, it gets a replica-aware stub
that has a reference to the home on each server that deployed the bean. When create()
or find() is called, the replica-aware stub routes the call to one of the replicas.
The home replica receives the find() results or creates an instance of the bean
on this server.

However, I want to invoke EJBs on a particular node in the cluster. Can Ido
this by simply disabling the replica-aware EJB home in the deploymentdescriptor
and doing a remote JNDI lookup on the desired node in the cluster? Andif so,
would I have to bind each EJB's home to JNDI with a different name?Yes. Something like that. We do that with JMS queues sometimes (to send a
message to a particular machine in the cluster).
Peace,
Cameron Purdy
Tangosol, Inc.
Clustering Weblogic? You're either using Coherence, or you should be!
Download a Tangosol Coherence eval today at http://www.tangosol.com/
"Behforooz" <[email protected]> wrote in message
news:3c8fc8bf$[email protected]..
>

Home Stub is bound or Home object is bound in JNDI

Hi,
When I lookup Home i get home stub at client side. My question is what is bound in JNDI tree Home stub or object of Home implementation class which is implemented by Server?
thanx

My understanding:
It is the stub that gets bound to the JNDI. From the client side, we look up the JNDI for the home stub. The stub knows how to communicate with it's corresponding server object(Home) thru the skeleteon(I think the concept of skeleton in RMI is deprecated now..)

Validating Cached Home Object

We cache the home objects to save on jndi lookups. But if the home
object belongs to a different application (something.ear), and
something.ear gets redeployed, the cached home object is no longer
valid.
Was wondering if there's a way to validate the cached home object.

Refer to
http://dataml.net/articles/ValidateXMLSchema/part1.htm

Can't cast home stub to home interface

WL 5.1
          NT4.0
          I'm trying to talk to an EJB from a servlet. I had been doing this successfully
          using tomcat for the servlet engine and WL as the app server. Now, I wish
          to get this working using WL's servlet engine and WL app server.
          I look up the home like this:
          (this class is in a base class)
          protected Object lookupHome( String jndiName, Class serviceClass ) throws NamingException
          InitialContext initialContext = new InitialContext();
          return javax.rmi.PortableRemoteObject.narrow( initialContext.lookup( jndiName ),
          serviceClass );
          (this class is a derived class)
          private FooHome getHome() throws NamingException
          return (FooHome)lookupHome( "Foo", Foo.class ); // !!!!!!!!!!!!<-----this cast fails
          The cast to (FooHome) fails, with a ClassCastException. I've looked at what is returned from the
          initialContext and after narrowing and the object is what it should be: FooHomeBeanImpl_ServiceStub.
          At anyrate, I compared what I get back using tomcat and what I get back using WL's servlet engine
          and
          they are the same.
          So the above works using tomcat/WL but fails for WL/WL.
          The obvious difference is that the tomcat -> WL involved to JVMs, one
          for tomcat, one for WL. I believe with WL-> WL there is only one JVM.
          I'm a bit baffled. Any clues would be very much appreciated.
          Thanks.


Yes, you will see many older messages in this forum related to this issue.
          The home and remote interfaces and any other classes "mentioned" therein are
          "exported" by the ejb jar class loader to the rest of the classes running on
          that instance of web logic.
          Cameron Purdy
          [email protected]
          http://www.tangosol.com
          WebLogic Consulting Available
          "Rich Johns" <[email protected]> wrote in message
          news:[email protected]...
          > Sorry to reply to my own, but I thought I'd report that I've fixed the
          > problem which was related to loading the same class from multiple jars.
          >
          > Apparently, (and admittedly I'm still a bit shaky on this) servlets can
          > see interfaces for already deployed EJBs loaded via the deployment jar.
          This means that you should
          > not load them for the benefit of the servlet on the servlet classpath. For
          example,
          > the servlet might need home and/or remote bean interfaces, but, since they
          > are already deployed beans, you don't need to explicitly put them on the
          > weblogic.httpd.servlet.classpath. I believe the same goes for WARs
          (whether
          > they are zipped or unfolded).
          >
          > Just what subset of classes in the deployment jar can be seen by a
          servlet? The
          > reason I ask this is because there are some classes in the deployment jar
          that
          > my servlet cannot see. These classes are not used by the deployed beans,
          but
          > they are used by the servlet. I had to make a separate jar containing
          these files.
          > (Eventually, they will not be part of the deployment jar.)
          >
          > So, is this a correct inference? Only files that the EJB classloader
          loaded,
          > which which is to say the EJB interfaces, stubs, and other classes used
          > by them, are actually visible to the servlet.
          >
          >
          > Rich Johns wrote:
          >
          > > WL 5.1
          > > NT4.0
          > >
          > > I'm trying to talk to an EJB from a servlet. I had been doing this
          successfully
          > > using tomcat for the servlet engine and WL as the app server. Now, I
          wish
          > > to get this working using WL's servlet engine and WL app server.
          > >
          > > I look up the home like this:
          > >
          > > (this class is in a base class)
          > > protected Object lookupHome( String jndiName, Class serviceClass )
          throws NamingException
          > > {
          > > InitialContext initialContext = new InitialContext();
          > > return javax.rmi.PortableRemoteObject.narrow(
          initialContext.lookup( jndiName ),
          > > serviceClass );
          > > }
          > >
          > > (this class is a derived class)
          > > private FooHome getHome() throws NamingException
          > > {
          > > return (FooHome)lookupHome( "Foo", Foo.class ); //
          !!!!!!!!!!!!<-----this cast fails
          > > }
          > >
          > > The cast to (FooHome) fails, with a ClassCastException. I've looked at
          what is returned from the
          > > initialContext and after narrowing and the object is what it should be:
          FooHomeBeanImpl_ServiceStub.
          > >
          > > At anyrate, I compared what I get back using tomcat and what I get back
          using WL's servlet engine
          > > and
          > > they are the same.
          > >
          > > So the above works using tomcat/WL but fails for WL/WL.
          > >
          > > The obvious difference is that the tomcat -> WL involved to JVMs, one
          > > for tomcat, one for WL. I believe with WL-> WL there is only one JVM.
          > >
          > > I'm a bit baffled. Any clues would be very much appreciated.
          > >
          > > Thanks.
          >

Questions on InitialContext and replica-aware stub caching

Hi All,
We have a cluster and deployed with some stateless ejb session beans. Currently we only cached the InitialContext object in the client code, and I have several questions:
1. in the current case, if we call lookup() to get a replica-aware stub, which server will return the stub object, the same server we get the InitialContext, or it will load balanced to other servers every time we call the lookup method?
2. should we just cache the stub? is it thread safe? if it is, how does the stub handle concurrent requests from the client threads? in parallels or in sequence?
One more question, when we call new InitialContext(), it will take a long time before it can return a timeout exception if the servers are not reachable, how can we set a timeout for this case?

809364 wrote:
You can set the timeout value programatically by using the
weblogic.jndi.Environment.setRequestTimeout()
Refer: http://docs.oracle.com/cd/E12839_01/apirefs.1111/e13941/weblogic/jndi/Environment.html
or
set the REQUEST_TIMEOUT in the weblogic.jndi.WLContext
Refer: http://docs.oracle.com/cd/E11035_01/wls100/javadocs/weblogic/jndi/WLContext.html
Hi, I tried setting the parameters before, but it only works for stub lookup and ejb call timeout, not for the creation of InitialContext. And any idea for my 2nd question?

Is it safe to cache stubs to SLSBs?

Hi,
I have a question which might actually be rather dumb: Is it safe to cache EJB3 stubs? Are they thread-safe?
In other words, if I perform a lookup like that:
MyBeanLocal myBeanLocal = (MyBeanLocal)ctx.lookup("...blah-blah...");can I then safely store the myBeanLocal stub somewhere and let multiple clients access it simultaneously?
I ran a short test with 10 concurrent threads accessing one and the same stub and calling a long-running method on the SLSB. They each managed to obtain a separate instance of the EJB from the pool and the long-running method was able to run in parallel.
But then again, even if the stub can produce different instances of the EJB, this doesn't necessarily mean that it's thread-safe or, even if it is, that it scales well for thousands of users.
Can anybody tell me what the best approach is?
Best regards,
Bisser

HI,
Cache can be deleted , i mean the entries can be refreshed.
see the below link
http://help.sap.com/saphelp_nw2004s/helpdata/en/0d/28e1c20a9d374cbb71875c5f89093b/content.htm
http://help.sap.com/saphelp_nw2004s/helpdata/en/c7/5c564077d96f13e10000000a1550b0/frameset.htm
http://help.sap.com/saphelp_nw2004s/helpdata/en/12/5dd23aaad7b3408dde3c1577fda5b3/content.htm
Regards
Chilla

JNDI lookups of home interface

JNDI lookups are expensive timewise. Our question is ... would it be
pratical to lookup all our EJB Home interfaces once at startup and store
these references in a global class accessible to all clients? These home
interfaces then become readily available factories for acquiring instances
of remote interfaces. Is there anything wrong with this picture? Is this a
problem because these home stubs are not reentrant and may be accessed
concurrently by more than one client? Is there a problem with have one home
reference create multiple remote references of an ejb?
Any light that can be shed on this question wouls be appreciated.
Thanks.
tiffany
San Diego

I'm using a Singleton class to cache HomeInterfaces. The first time a
HomeInterface is requested, the JNDI lookup is done, after that, all
requests to that HomeInterface are handled by the cache. Works great, no
problems. AFAIK there are no problems with storing the HomeInterface
reference and reusing it.
Hope that helps,
Nils
Tiffany wrote:
>
JNDI lookups are expensive timewise. Our question is ... would it be
pratical to lookup all our EJB Home interfaces once at startup and store
these references in a global class accessible to all clients? These home
interfaces then become readily available factories for acquiring instances
of remote interfaces. Is there anything wrong with this picture? Is this a
problem because these home stubs are not reentrant and may be accessed
concurrently by more than one client? Is there a problem with have one home
reference create multiple remote references of an ejb?
Any light that can be shed on this question wouls be appreciated.
Thanks.
tiffany
San Diego--
============================
[email protected]

Can't invalidate the CMP bean's cache. Please help

Dear all,
The ClassCastException raised while calling:
(weblogic.ejb.CachingLocalHome)home).invalidate (Arrays.asList(primaryKeys));
The CMP bean uses optimistic concurrency and caching between transactions.
<b> Please advice what weblogic-ejb-jar.xml attributes may be set to cause Weblogic generate proper Home stub that may be cast to CachingLocalHome?</b>
P.S. weblogic-ejb-jar.xml :
<weblogic-enterprise-bean>
<ejb-name>MyEntity</ejb-name>
<entity-descriptor>
<entity-cache>
<concurrency-strategy>Optimistic</concurrency-strategy>
<cache-between-transactions>True</cache-between-transactions>
</entity-cache>
</entity-descriptor>
</weblogic-enterprise-bean>

check the documentation for invalidation of RO entity beans there is example code to invalidate on OCE.
http://e-docs.bea.com/wls/docs81/ejb/entity.html#ChoosingaConcurrencyStrategy

HTTP Session caching possible using WL7 JAX-RPC ?

We're using WL7, and using the JAX-RPC API to access external webservices.
Basically, we create the appropriate 'stubs' from the target WSDL using
clientgen. Then we invoke the target method. Code looks something like this:
Client_Impl client = new Client_Impl; // implementation of target
ClientPort_Stub stub = client.getClientPort();
stub._setProperty(javax.xml.rpc.Stub.ENDPOINT_ADDRESS_PROPERTY, url)
stub.invoke(args);
Now, when is the actual endpoint URL being created ? Is it when the invoke()
method is called ?
It cannot be during the constructor since I pass the target URL after that ...
My problem is that I have to call the 'invoke' method quite frequently, and hence
would like the HTTP session to be reused, rather than recreated each time. Right
now,
I construct the stub each time I have to call the target method, and I'm wondering
if
I just cache the stub and keep calling the target method each time, will the underlying
HTTP session be reused ? Any ideas ?
Currently, if I do netstat on my Sun Solaris box (where this runs), I see the
TCP
connection being recreated during each invocation ...
-john

Hi John,
You can do multiple invokes on the same stub. There is no
need to create a new one for each invoke.
WLS 7.0 use HTTP 1.0 with keep alive. If the server respects
HTTP keep alive, then WLS will not create a new connection.
HTHs,
-manoj
"john" <[email protected]> wrote in message news:[email protected]..
>
We're using WL7, and using the JAX-RPC API to access external webservices.
Basically, we create the appropriate 'stubs' from the target WSDL using
clientgen. Then we invoke the target method. Code looks something likethis:
>
Client_Impl client = new Client_Impl; // implementation of target
ClientPort_Stub stub = client.getClientPort();
stub._setProperty(javax.xml.rpc.Stub.ENDPOINT_ADDRESS_PROPERTY, url)
stub.invoke(args);
Now, when is the actual endpoint URL being created ? Is it when theinvoke()
method is called ?
It cannot be during the constructor since I pass the target URL after that...
My problem is that I have to call the 'invoke' method quite frequently,and hence
would like the HTTP session to be reused, rather than recreated each time.Right
now,
I construct the stub each time I have to call the target method, and I'mwondering
if
I just cache the stub and keep calling the target method each time, willthe underlying
HTTP session be reused ? Any ideas ?
Currently, if I do netstat on my Sun Solaris box (where this runs), I seethe
TCP
connection being recreated during each invocation ...
-john

CMP cache

Hi
I am working on a task which requires creating a cache(using hashtables probably) so that the components donot need to invoke the finder methods of the CMP beans all the time.
Reason for doing this:
1. the finders cannot utilize CMP cache because there are not findByPrimaryKey
2. a large number of calls are being made to these finder methods.
Query:
1. Is it correct that we cannot have CMP cache because these finders are not findByPrimaryKey?
2. If I create cache, is there any mechanism to make sure that the cache information is not inconsistent with the database?

Usually the home interface does this for you...
It is deprecated to use a hashtable because the entity beans you cached can get invalid or deleted. I'm quite sure the server will throw some kind of exception if a requested bean is not present anymore. So i you still want to cache youll have to implement some own logic how to handle inconstencies.
Still the home interface usually does a really good job and it is the only part in CMP which can be cached (ServiceLocator pattern does it BTW).
Finders are compiled at deploytime and use database querries so you wont be able to use them on your cache.
Fazit: consider caching home interfaces because their lookup is expensive (JNDI) and use those to access your entity beans.

Home object one for each client

1.
When client looks up for home (context.lookup("TraderHome")) :-
1.Client gets the Home Stub which was implemented by the Server, is it correct ?
2.On the server who will communicate with this client homestub? One home-object for on server ? Is it correct ?
3. So Client home-stub and server-home object one-to-one communication ?
4. Will the home-stub object carries any context from server ?(like security or user-specific context ?
5. Can we restrict so that certain user can only get the home object ?
please make me clear ...
-thanks
Praveen Sadhu.

When client looks up for home (context.lookup("TraderHome")) :-
1.Client gets the Home Stub which was implemented by the Server, is it correct ?
2.On the server who will communicate with this client homestub? One home-object for on server ? Is it correct ?
3. So Client home-stub and server-home object one-to-one communication ?
4. Will the home-stub object carries any context from server ?(like security or user-specific context ?
5. Can we restrict so that certain user can only get the home object ?
please make me clear ...
-thanks
Praveen Sadhu.

ICal: upgrade to OS 10.6 has created double home, work & unfiled calendars.

Having finally upgraded to OS 10.6.4 on my Macbook Pro, iCal now displays two home, two work and two unfiled calendars. My subscribed calendars haven't changed.
They are not duplicates, but each contain portions of my original, single versions of those calendars, so I'm unable to delete any of them.
I know I can create group versions of my calendars and put the doubles under a single heading, but is there any way to merge these fraternal twin calendars?
Thanks!

Welcome to Apple Discussions,
First make an iCal backup, File > Export > Archive.
Remove the following to the trash and restart your computer:
Home > Library > Caches
Home > Library > Calendars > Calendar Cache, Cache, Cache 1, 2, 3, etc. (Do not remove Sync Cache or Theme Cache)
Home > Library > Preferences > com.apple.ical (There may be more than one of these. Remove them all.)
__NOTE: Removing these files will remove any shared (CalDAV) calendars you may have access to. You will have to re-add those calendars to iCal > Preferences > Accounts.
Once the computer is back up and running open iCal and test.
Hope that helps.

Web application Unloading classes of WL Stubs every several hours

Hello,
We have a WEB applications, which connects to Server Application using EJB technology - both deployed on the same
domain on Weblogic 10.
Recently, we started to experience a strange phenomenon - WEB application's threads get stalled and get a STUCK
state.
Sometimes, it is accompanied with the java.lang.OutOfMemoryError exception.
Only reboot helps to recover from it.
Trying to identify a problem we added some parameters to get some more information in the application logs.
What we found is that once in a while (depend on a system load), we see the following messages in console logs:
[Unloading class <class name>]
These are the examples about how often the events happen and it’s durations:
2011-01-30 10:14:11 - 2011-01-30 10:14:28
2011-01-30 12:27:51 - 2011-01-30 12:28:08
2011-01-30 13:59:46 - 2011-01-30 14:00:02
2011-01-30 14:56:59 - 2011-01-30 14:57:13
2011-01-30 14:57:46 - 2011-01-30 14:58:00
2011-01-30 17:11:21 - 2011-01-30 17:11:39
2011-01-30 18:29:24 - 2011-01-30 18:29:44
2011-01-30 20:05:34 - 2011-01-30 20:05:53
2011-01-30 21:48:39 - 2011-01-30 21:48:55
. - Each time are about 20000 - 30000 classes are unloaded.
. - About 150000 classes are unloaded daily,
........- 90% out of it are the classes, which ends with "*..Impl_1001_WLStub*"
............- 30% out of Stubs are Home Stubs, which ends with "*..HomeImpl_1001_WLStub*"
*(!) The most interesting that out of all this huge amount of classes, which are unloaded daily,*
only +23+ types of different Stubs are unloaded, whereas out of it +10+ different Home Stubs:
$> grep "Unloading class.*Impl_1001_WLStub" Web1.out | sort -u | wc -l
23
$> grep "Unloading class.*HomeImpl_1001_WLStub" Web1.out | sort -u | wc -l
10Sometimes (as I said above) it ends with the "+java.lang.OutOfMemoryError+" exception.
So, the questions are:
1. What could be a reason for such behavior of a system?
2. What message "Unloading class" says?
3. Is it normal that (as you see from above), the same type of Stubs are loaded?
It looks like a new Stub is created for every EJB invocation, isn't it?
Is it normal? If not, what could be a reason for this?
--------------- S Y S T E M ---------------
jvm_args: -Xms2048m -Xmx2048m -XX:MaxPermSize=512m
OS: Solaris 10 5/08 s10s_u5wos_10 SPARC
uname:SunOS 5.10 Generic_142900-02 sun4v (T2 libthread)
rlimit: STACK 8192k, CORE 1024000k, NOFILE 65536, AS infinity
CPU:total 64 has_v8, has_v9, has_vis1, has_vis2, is_ultra3, is_sun4v, is_niagara1
Memory: 8k page, physical 66977792k
vm_info: Java HotSpot(TM) Server VM (1.5.0_11-b03) for solaris-sparc, built on Dec 15 2006 01:18:11

You could see how your memory is managed by the JVM, by using for example a tool such as jconsole.
Unloading class means that loaded classes are garbage collected. To see when the classes are loaded
you can use the JVM option -verbose:class. I think somehow you are constantly loading the classes in the application,
maybe by creating the stub over and over again when you need it. You can create the stub once by using
a singleton pattern.
A good overview of the available tools for the Sun JVM is given here: http://www.oracle.com/technetwork/java/javase/index-137495.html

Is it OK to cache home stubs in 6.1?

Similar Messages

Maybe you are looking for