Yes, entity beans are cached, but only if you don't have a cluster!
In a cluster, container will typically read entity bean's data before any
method invocation and store after it. This will be a huge perfomance
problem.

Here's an article on the topic
http://www.theserverside.com/resources/article.jsp?l=DB_Break

Best regards,
Serge Adzinets

----- Original Message -----
From: "Jeff Jensen" <jeffjensen@(protected)>
To: <J2EE-INTEREST@(protected)>
Sent: Friday, January 09, 2004 5:41 PM
Subject: Re: Shared cache best practices?


> Not knowing your situation and special needs that dictate creation of a
custom
> data caching service, Devil's advocate here...
>
> A performant application usually caches some data. There are a number of
> benefits to using entity beans, including the data caching they do for
> you, "for free".
>
> Are you sure the caching done by the entity beans is not enough for your
> situation?
>
> What are the decision points that lead you to think the application
requires
> extra caching?
>
> You could encounter plenty of development work to add your own caching and
> problems from its use for little gain. Be sure the gain is worth the
extra
> layer's development, debugging, and maintenance!
>
>
> -----Original Message-----
> From: Erik Beijnoff [mailto:erik@(protected)]
> Sent: Friday, January 09, 2004 8:41 AM
> To: J2EE-INTEREST@(protected)
> Subject: Re: Shared cache best practices?
>
>
> Ok. Nice to hear another opinion. It's always good to get another view on
> things.
>
> My problem in short was how to keep caches living on separate machines in
synch
> with each other, when the underlying data (database) may be changed
without the
> caches being aware of it. The response was mostly to redesign my
implementation
> to use Entity Beans with a Facade that I communicated with that in turned
had
> single access to the database.
>
> I myself had an idea of letting the caches register themselves in a single
> location, and then handle invalidation requests from the updating
application
> server through HTTP or RMI whenever any of the application servers updates
the
> database.
>
> I'm not sure how I will handle it, the implementation is a month or two
away,
> so I'll think about it until then. What you describe may be applicable.
We'll
> see.
>
> Regards Erik Beijnoff
> -----Ursprungligt meddelande-----
> Från: A mailing list for Java(tm) 2 Platform, Enterprise Edition
[mailto:J2EE-
> INTEREST@(protected)
> Skickat: den 8 januari 2004 18:47
> Till: J2EE-INTEREST@(protected)
> Ämne: Re: Shared cache best practices?
>
>
> Entity beans are not really a good solution for any situation and I think
> should be culled from the herd of J2EE. I don't recommend you go down that
path
> as it will not likely give you good performance, scalability, or reduced
> complexity. I have a large CMP Entity Bean application (luckily
successful) and
> I am warning you away from this approach.
>
> I didn't really hear enough about your situation to suggest a good caching
> mechanism. The approach I took was to front my EJB calls with a wrapper
who
> returns cached data if the data has not been invalidated, when data is
posted,
> objects in the cache are invalidated via a notification to each
invalidated
> cached object (objects register to be notified when they are put in the
cache).
> But again, I don't know if this is applicable to your situation.
>
> Regards
> Steve
> -----Original Message-----
> From: A mailing list for Java(tm) 2 Platform, Enterprise Edition
[mailto:J2EE-
> INTEREST@(protected)
> Sent: Thursday, January 08, 2004 12:38 AM
> To: J2EE-INTEREST@(protected)
> Subject: Re: Shared cache best practices?
>
>
> Thanks for the responses. You've been verry helpful. I've gotten some
> alternative approaches to think of it, and those of you who have answered
seems
> to lean towards the Entity Beans approach.
>
> > Depending on your container, you may get automatic invalidation for
free -
> > by using the appropriate "commit option" (without needing JMS).
> > This is all assuming that all modifications to the tables that have the
> cached data are being done through entity beans.
> > In any event, it seems entity beans would be a good fit. You will need
to
> decide whether to
> > keep your strategy of separate caches per web server (which will mean an
app
> server local to each web server).
>
> For the moment I am not using Entity Beans or EJB. Just a domain model
made out
> of Pojos manipulated through a DB Peer, so it's really not an app server
for
> each web server, rather several web server with caches. If I where to use
> Entity Beans, do they make a good joob replicating over several servers,
or can
> I expect the app server holding the Entity Beans to become a bottleneck in
the
> future?
>
> Best regards Erik Beijnoff
>
>
===========================================================================
> To unsubscribe, send email to listserv@(protected)
body
> of the message "signoff J2EE-INTEREST". For general help, send email to
> listserv@(protected)".

===========================================================================
To unsubscribe, send email to listserv@(protected)
of the message "signoff J2EE-INTEREST". For general help, send email to
listserv@(protected)".