• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • Liutauras Vilda
  • Jeanne Boyarsky
  • paul wheaton
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Henry Wong
Saloon Keepers:
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Tim Moores
  • Mikalai Zaikin
Bartenders:
  • Frits Walraven

Basic JNDI caching questions.

 
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am new to Websphere and J2EE and I have some very basic questions on JNDI caching.
It would be very helpful if someone could clarify all of them. I went through the Infocenter (updated one for Fixpack 2 -http://www-4.ibm.com/software/webservers/appserv/doc/v35/ae/infocenter/was/040302.html), it claims to have implemented Jndi caching by default during lookups. I have the following doubt,
1. The article says that 'A cache is restricted to a process and does not persist past the life of the process'. Here what does PROCESS mean? Is the process the one between the start and stop of the EJB container? If we have many EJB containers (default container and other containers) then does that mean that we have multiple processes running?
2. What is the difference between JNDI reference caching and caching EJB homes ?
3. What is the 'cached object'? What exactly gets cached? Is it the EJB home interface?
4. The article furthur says the following:
'If a bind or rebind operation is executed on an object, the change will not be reflected in any caches other than the one associated with the context from which the bind or rebind was issued. This "stale data" scenario is most likely to happen when multiple processes are involved, since different processes do not share the same cache, and Context objects in all threads in a process will typically share the same cache instance for a given name service provider'.
a. What is the bind and rebind operation? I found out that they are methods in javax.naming.Context. But what is meant exactly by binding an object to the string.
b. When does a 'stale data' scenario occur? When we deploy the same EJB in multiple containers (and hence cached in multiple caches)?
Thanks in advance,
Krithika

------------------
Krithika
 
Ranch Hand
Posts: 1157
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I am attempting to answer some of your questions.I believe internally Caching would be implemented on Singleton Pattern.
What is the difference between JNDI reference caching and caching EJB homes ?
When we refer to JNDI caching, probably it means "com.ibm.ejs.ns.jndi.CNInitialContextFactory" would search for th e provider URL (iiop://...).Since each part of the provider URL would be implemented as a Java class, hence the CNInitialContextFactory would be implemented using a Singleton pattern to give the global instance of the Context that has been created earlier using the provider URL.
Caching EJB Home is what you implement while you code a EJB Component.Again it involves validating if the instance has been created earlier or not.If yes, the same instance is returned otherwise the new instance is created.

What exactly gets cached? Is it the EJB home interface?
Yes, we can cache the EJB Home interface by using Singleton Pattern.
What is the bind and rebind operation?
You can bind an object with a name in the session namespace.However, if you use bind you cannot bind the object again with the same name.If you want to that, you would need to unbind the previous mapping and bind it with a new name.This is done by the rebind operation.
what is meant exactly by binding an object to the string?
This is the basic principle on how JNDI works.Instead of remembering the exact structure of the object, you are representing that object with a simplified name which the clients may want to refer to.You may think of JNDI service as a giagantic Collection which maps Objects to simple Strings for accessing objects.
The article says that 'A cache is restricted to a process and does not persist past the life of the process'. Here what does PROCESS mean?
This infact depends on the architecture of the AS.I am new to Websphere environment.I can tell you about a process in Oracle Application Server, where a request by the client would be handled by a seperate lightweight process called sess_iiop (based on some logic).Each of these processes will have its own set of static and non-static variables.These variables are not shared between processes.
When does a 'stale data' scenario occur?
As mentioned in the note that you posted, it occurs when many processes are executing together.This statement "Usually, cached objects are relatively static entities, and objects becoming stale should not be a problem." signifies the use of Singleton pattern which sees to it that stale data doesnot create a problem for us.
Hope this helps,
Sandeep
[This message has been edited by Desai Sandeep (edited June 22, 2001).]
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Sandeep,
The info about JNDI is great. I have a query about the same.
Is there any way to confirm that the EJBHome obtained is definitely catched/not catched?
Regards,
Gururaj.

Originally posted by Desai Sandeep:
Hi,
I am attempting to answer some of your questions.I believe internally Caching would be implemented on Singleton Pattern.
[b]What is the difference between JNDI reference caching and caching EJB homes ?

When we refer to JNDI caching, probably it means "com.ibm.ejs.ns.jndi.CNInitialContextFactory" would search for th e provider URL (iiop://...).Since each part of the provider URL would be implemented as a Java class, hence the CNInitialContextFactory would be implemented using a Singleton pattern to give the global instance of the Context that has been created earlier using the provider URL.
Caching EJB Home is what you implement while you code a EJB Component.Again it involves validating if the instance has been created earlier or not.If yes, the same instance is returned otherwise the new instance is created.

What exactly gets cached? Is it the EJB home interface?
Yes, we can cache the EJB Home interface by using Singleton Pattern.
What is the bind and rebind operation?
You can bind an object with a name in the session namespace.However, if you use bind you cannot bind the object again with the same name.If you want to that, you would need to unbind the previous mapping and bind it with a new name.This is done by the rebind operation.
what is meant exactly by binding an object to the string?
This is the basic principle on how JNDI works.Instead of remembering the exact structure of the object, you are representing that object with a simplified name which the clients may want to refer to.You may think of JNDI service as a giagantic Collection which maps Objects to simple Strings for accessing objects.
The article says that 'A cache is restricted to a process and does not persist past the life of the process'. Here what does PROCESS mean?
This infact depends on the architecture of the AS.I am new to Websphere environment.I can tell you about a process in Oracle Application Server, where a request by the client would be handled by a seperate lightweight process called sess_iiop (based on some logic).Each of these processes will have its own set of static and non-static variables.These variables are not shared between processes.
When does a 'stale data' scenario occur?
As mentioned in the note that you posted, it occurs when many processes are executing together.This statement "Usually, cached objects are relatively static entities, and objects becoming stale should not be a problem." signifies the use of Singleton pattern which sees to it that stale data doesnot create a problem for us.
Hope this helps,
Sandeep
[This message has been edited by Desai Sandeep (edited June 22, 2001).][/B]


 
author
Posts: 3892
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
(Metacomment -- I appreciate Desai's great effort, but as he stated, he was guessing. In fact, this is the way it works -- I know since I've seen the code and I've spoken to the developers about this on many occasions).

Originally posted by Krithika Venugopal:
I am new to Websphere and J2EE and I have some very basic questions on JNDI caching.
It would be very helpful if someone could clarify all of them. I went through the Infocenter (updated one for Fixpack 2 -http://www-4.ibm.com/software/webservers/appserv/doc/v35/ae/infocenter/was/040302.html), it claims to have implemented Jndi caching by default during lookups. I have the following doubt,
1. The article says that 'A cache is restricted to a process and does not persist past the life of the process'. Here what does PROCESS mean? Is the process the one between the start and stop of the EJB container? If we have many EJB containers (default container and other containers) then does that mean that we have multiple processes running?


No. Process means just that, PROCESS, as in operating systems process == JVM. When the JVM shuts down the cache is gone since it's held in memory in the JVM along with everything else.


2. What is the difference between JNDI reference caching and caching EJB homes ?


There is no difference. EJB Home references are what is cached. Here's what happens. In WebSphere EJB Homes are registered with JNDI by serializing an EJB reference (an IOR) and placing it in the administrative database. Our CosNaming Service that our JNDI is implemented on top of handles the serialization and storage. Now, in previous versions of WebSphere, each lookup() in JNDI would actually have to do the following:
(1) The JNDI InitialContext would contact the CosNaming Service which is a thread running on the Admin Server (at port 900, naturally) and request the reference at some name.
(2) The CosNaming Service would then look in the database and see if the name is there. If it is it would retrieve the reference from the database and return it.
Now, this is obviously going to be slow, since it involves both crossing the network and doing a database query for each lookup()method. So, in WebSphere 3.5.3 (I think -- maybe 3.5.2) we added a cache on the client end (meaning inside our InitialContext implementation, but outside of any particular instance -- the cache is shared among all InitialContext instances in a JVM). What happens is that once a Home reference has been retrieved by a lookup() method, it is held in the cache and any further lookup() methods with the same argument will return back the cached value, and not recontact the CosNaming Service.
Thus, it is no longer as advantageous to you the programmer to cache EJB homes in your programs as it used to be in older versions of WebSphere. You can gain a tiny bit of performance by doing so, but not the huge performance gains that were true of earlier versions.


3. What is the 'cached object'? What exactly gets cached? Is it the EJB home interface?


Yes, see above. Actually, we say "cached object" because you can store things other than Home referencs in JNDI (for instance DataSource references). You can actually put any Serializable Java object in our JNDI implementation in 4.0, although there were some problems with doing this in 3.5. Whatever they are, they are cached in the same way.


4. The article furthur says the following:
'If a bind or rebind operation is executed on an object, the change will not be reflected in any caches other than the one associated with the context from which the bind or rebind was issued. This "stale data" scenario is most likely to happen when multiple processes are involved, since different processes do not share the same cache, and Context objects in all threads in a process will typically share the same cache instance for a given name service provider'.
a. What is the bind and rebind operation? I found out that they are methods in javax.naming.Context. But what is meant exactly by binding an object to the string.
b. When does a 'stale data' scenario occur? When we deploy the same EJB in multiple containers (and hence cached in multiple caches)?


Desai's description of bind and rebind is pretty good. This is just standard JNDI. The "stale data" scenario could ONLY happen in cases where you yourself are putting things in JDNI. Don't worry about it.
Now your question about "putting the same EJB in multiple containers" makes me think that you don't really understand how WebSphere works. There is ONE SINGLE GLOBAL NAMESPACE for all EJB containers and Application Servers in WebSphere. Each container does NOT get its own namespace. If you deploy an EJB with the same name twice, the second overwrites the first. So if you were planning something clever involving multiple containers and deployment of the same EJB multiple times, it's not going to work.
BTW, the reason this is true is that our built-in load balancing is what requires you to have a single namespace -- please go to http://www.redbooks.ibm.com and download the WebSphere 3.5 Workload Management redbook -- it will explain this in great detail.


Thanks in advance,
Krithika


Kyle

------------------
Kyle Brown,
Author of Enterprise Java (tm) Programming with IBM Websphere
See my homepage at http://members.aol.com/kgb1001001 for other WebSphere information.
 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi
I want to make sure I undestand the jndi caching of WAS. I try the below example:
I have a standalone application accessing the objects in remote WAS 3.5 using jndi, I write the following code:
================================================
env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.ibm.ejs.ns.jndi.CNInitialContextFactory");
env.put(Context.PROVIDER_URL, "iiop://remotehost");
Context ctx = new InitialContext(env);
ctx.lookup("myObject");
=================================================
In this case, a cached copy of myOject will be stored in the local machine. If I lookup myObject again, then this cached copy will be returned instead of actually lookup. Right? If I want to get a remote copy, can I use the following code to do so?
================================================
env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.ibm.ejs.ns.jndi.CNInitialContextFactory");
env.put(Context.PROVIDER_URL, "iiop://remotehost");
env.put("com.ibm.websphere.naming.jndicache.cacheobject","cleared");
Context ctx = new InitialContext(env);
ctx.lookup("myObject");
=================================================
Please correct me if I am wrong.

Thank you
Leo
 
Kyle Brown
author
Posts: 3892
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Leo, you're right.
Kyle
 
My previous laptop never exploded like that. Read this tiny ad while I sweep up the shards.
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
reply
    Bookmark Topic Watch Topic
  • New Topic