Caching EJBObject reference of stateless session bean - Java
This is a discussion on Caching EJBObject reference of stateless session bean - Java ; What are the pros / cons of caching the EJBObject reference of a
stateless session bean?
Say we have stateless session bean Bean1 that invokes another
stateless session bean Bean2. It is common to cache the home reference
of Bean2 ...
-
Caching EJBObject reference of stateless session bean
What are the pros / cons of caching the EJBObject reference of a
stateless session bean?
Say we have stateless session bean Bean1 that invokes another
stateless session bean Bean2. It is common to cache the home reference
of Bean2 as an instance variable of Bean1. Why not simply cache the
EJBObject of Bean2 as well? It seems to work and makes quite a
difference in performance.
-
Re: Caching EJBObject reference of stateless session bean
Jacek Korycki schrieb:
> What are the pros / cons of caching the EJBObject reference of a
> stateless session bean?
> Say we have stateless session bean Bean1 that invokes another
> stateless session bean Bean2. It is common to cache the home reference
> of Bean2 as an instance variable of Bean1. Why not simply cache the
> EJBObject of Bean2 as well? It seems to work and makes quite a
> difference in performance.
I think your question is closely related to the discussion whether a
service locator in the ejb tier should use caching or not. Some people
say no, the caching of ejbs should be the task of the container. However
since you use stateless beans which do not need activation or
passivation I don't see any problems arising. I might be a problem with
stateful beans.
-marek
-
Re: Caching EJBObject reference of stateless session bean
korycki@netscape.net (Jacek Korycki) wrote:
> What are the pros / cons of caching the EJBObject reference of a
> stateless session bean?
>
> Say we have stateless session bean Bean1 that invokes another
> stateless session bean Bean2. It is common to cache the home reference
> of Bean2 as an instance variable of Bean1. Why not simply cache the
> EJBObject of Bean2 as well? It seems to work and makes quite a
> difference in performance.
It is very reasonable for stateless session beans. The EJB
Specification says:
"All session objects of the same stateless session bean within
the same home have the same object identity, which is assigned
by the container. If a stateless session bean is deployed
multiple times (each deployment results in the creation of a
distinct home), session objects from different homes will have a
different identity." (Section 6.9.2 in EJB 2.0 Specification)
For stateful beans, you (obviously) need separate EJBObject references
for the separate uses.
The only 'con' is that the client must be aware that the bean is
stateless if it is going to do this. Most clients are already coded
for stateless beans anyway (they don't 'remove' the bean when they're
done), so this is not much to be concerned about.
Similar Threads
-
By Application Development in forum Java
Replies: 2
Last Post: 08-02-2005, 02:30 AM
-
By Application Development in forum Java
Replies: 3
Last Post: 04-12-2005, 04:57 PM
-
By Application Development in forum Java
Replies: 1
Last Post: 06-07-2004, 07:31 AM
-
By Application Development in forum Java
Replies: 0
Last Post: 06-03-2004, 05:16 AM
-
By Application Development in forum Java
Replies: 1
Last Post: 12-11-2003, 02:33 PM