Entity Beans and Caching

Question

Hi,
My environment is:
- Weblogic 5.1 running on Solaris
- Oracle 8i database server
- Two physical servers clustered together to form one logical server
I can possibly upgrade to Weblogic 6 or later if it'll help solve my
problem.
Here's what I'm trying to accomplish:
I want to write entity beans using bean-managed persistence. The BMP
part of it is strongly preferred because our DBAs like to see and tune
all of the queries we send from the application.
In many cases, the data I'm querying is largely static. I want to
write EJBs that will cache the data in memory and avoid reading it
from the database server every time the EJB is invoked, unless it
knows that the data has changed.
I've done this successfully with single-server installations, but I'm
not sure how it'll work with a clustered server. Assuming nothing
outside of my two Weblogic servers is updating my database, can I
configure the EJB to have exclusive access to the database and count
on Weblogic to manage the state between the two servers? Or do I have
to implement some kind of custom signalling scheme so that an EJB in
one container can notify any EJBs in the other container with the same
primary key when it has updated the underlying data?
I know from experience that the container will call the ejbStore()
method whenever a transaction ends. My usual BMP pattern in the past
has been to keep track of whether any data has changed during the
transaction and update only those database columns, if any, that
actually changed. But I don't think the store method has any way of
notifying the container as to whether or not it actually stored
anything; hence, I can't see how the container would know when to
order the entity bean on the opposite server to reload itself.
Thanks.

Answer 1

The 6.1 implements functionality you want:
http://e-docs.bea.com/wls/docs61/ejb/EJB_environment.html#1121105
if you use 5.1 you can use this approach:
http://dima.dhs.org/misc/readOnlyUpdates.html
Frank LaRosa <[email protected]> wrote:
Hi,
My environment is:
- Weblogic 5.1 running on Solaris
- Oracle 8i database server
- Two physical servers clustered together to form one logical server
I can possibly upgrade to Weblogic 6 or later if it'll help solve my
problem.
Here's what I'm trying to accomplish:
I want to write entity beans using bean-managed persistence. The BMP
part of it is strongly preferred because our DBAs like to see and tune
all of the queries we send from the application.
In many cases, the data I'm querying is largely static. I want to
write EJBs that will cache the data in memory and avoid reading it
from the database server every time the EJB is invoked, unless it
knows that the data has changed.
I've done this successfully with single-server installations, but I'm
not sure how it'll work with a clustered server. Assuming nothing
outside of my two Weblogic servers is updating my database, can I
configure the EJB to have exclusive access to the database and count
on Weblogic to manage the state between the two servers? Or do I have
to implement some kind of custom signalling scheme so that an EJB in
one container can notify any EJBs in the other container with the same
primary key when it has updated the underlying data?
I know from experience that the container will call the ejbStore()
method whenever a transaction ends. My usual BMP pattern in the past
has been to keep track of whether any data has changed during the
transaction and update only those database columns, if any, that
actually changed. But I don't think the store method has any way of
notifying the container as to whether or not it actually stored
anything; hence, I can't see how the container would know when to
order the entity bean on the opposite server to reload itself.
Thanks.--
Dimitri