Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Caching remote reference  RSS feed

 
kiran mahavir
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,
Please suggest/correct if what i am doing is correct regarding the caching of EJB references in the web tier. What i am doing is as follows
1) A java bean gets the required dat from the EJB tier.
2) This bean is put in the session as it will be used at different points of time in the users session.
3) The java bean implements HttpSessionBindingListener.
4) In the contructor of the java bean i am looking up the home and getting the referece of the required EJB(stateless)
5) The look up is through service locator which caches the home references.
6) I am storing the remote reference as a member variable
7) Invoking the remove method on the remote referece in the valueUnbound() method.
8) The rest of the methods use the remote reference when called.
This is what i am doing (In case of stateful also). Is this correct ? I face no problems as of now regarding performance. Its better than when the remote reference is fetched in each method invocation of the java bean. Does what i am doing leads to any problems later?
(I have read threads in jguru which say we can cache the references in application/session contexts. Some opined to use Handles, which might make the application slow as it involves IO. Thats the reason i used the remote reference as a member variable)
Thanks in advance
Kiran
 
Vijayakumar Arya
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
It is okay in caching the remote reference of stateless session beans. Caching stateful session beans are to be avoided, let me explain why.
The bean container doesnot create 1 instances per request for bean, instead it maintains a pool of bean instances and returns the reference of a free bean from the pool. In case of heavy demand, the container activates and passivates the bean so that it can cater the need for the raising demand. Some times the container might even remove a bean from the bean pool, it depends on the bean container.
In case, let us take you are caching the remote reference of a stateful bean. Mean while, the container had passivated the state of the bean and loaded the state of another request, but the reference remains the same(bean instance is re-used). If you use the reference to access the bean, that would not contain your state but the state of another request. To prevent this always use handles if you want to cache the stateful session beans.
-----------------------------
The hand that gives, gathers....
 
kiran mahavir
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi vijay thanks for the reply.You wrote
-----------------------------------------------
<b>
The bean container doesnot create 1 instances per request for bean, instead it maintains a pool of bean instances and returns the reference of a free bean from the pool. </b>
-----------------------------------------------
But there is no instance pooling in case of Stateful session beans.
Regarding the caching in http session, i came across threads in developer.bea.com and jguru which says you can cache the reference of the stateful bean.
Even if we use handles,in which the remote reference gets serialized.This is same as caching the session, which will avoid the IO required for serialization.
If time permits me i'll post the URLs which I read at jguru and bea in the same thread.
regards
Kiran
 
Thomas Taeger
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by kiran mahavir:
... you can cache the reference of the stateful bean.
... use handles, ... avoid the IO required for serialization.

Is it not the other way around: serialization required for IO?
Serializing methods like writeObject() are called in case of IO.
And you are right, you can cache Handles, i.e. even write them to disk, pass them to another client (must be in an other JVM because
R. Adatia e.a.: "Professional EJB", page 98:
references to remote objects in EJB are single-threaded.

I know this article about Handles in stateFULL session beans: R. Adatia e.a.: "Professional EJB", pages 37.. and p.98..).
Originally your aim was:
Originally posted by kiran mahavir:
6) I am storing the remote reference as a member variable

Isn't using a Handle the only way of caching a reference to a statefull session bean that is guaranteed by the spec and therefore is portable?
It does what you probabely intended: Avoid the time costly JNDI lookup.
But as far as I can imagine using a Handle does not avoid serialization of the session bean itself; not the bean is cached, only the Handle. The Handle is just a short-cut reference to the stateful session bean instance. For me it is like a pointer on a pointer on an object, allowing the object to be moved to somewhere else in memory, just affecting the inner pointer, and thereby giving the container the freedom and flexibility it needs to effectively administer resources.
"Caching a direct Java reference to a statefull session bean", what could it mean?
- Holding it in a local variable? Ok.
- Saving it to a cache for example in ejbPassivate() of another, calling bean? No, because the reference is not serializable, only the Handle is.
Hope I am not quite wrong...
Thomas.
 
kiran mahavir
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
HI Thomas, nice to see your reply.
Coming to the point, I am not passing the remote reference of the Stateful Session Bean. I am storing it as a member variable and using it in different methods of the Java Bean (in which i declare the remote referece as a member variable), which i will be invoked at diffent points in the users session.
As i am not passing this remote reference to any other object, I prefered not to use Handle.
Whats your opinion on what i am doing. Is it right?
regards
Kiran
 
Thomas Taeger
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by kiran mahavir:
As i am not passing this remote reference to any other object, I prefered not to use Handle.

Hi Kiran,
first: You should allways provide the readers with the scenario and facts they need to understand, help and/or answer.
- JavaBean or Enterprise JavaBean (EJB)? Totally different!
Scenario?:
- An ordinary JavaBean is to call methods of an Enterprose JavaBean?
- You wunder if you should keep a reference in the ordinary JavaBean to the session EJB?
- What objects in which tiers and in which container will use the ordinary JavaBean (if it is any)? JSPs? ...?
Thomas.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!