Does an EntityBean synchronize with the database when get methods are called
in Mode B caching?

I'm trying to determine which caching mode to operate in. I require fault
tolerance and clustered load balancing. That has pushed me into using
EntityBean EJB. The specification allows three modes of caching. I desire
caching of the entity in memory to improve performance of read only
operations (i.e., get methods) following an ejbStore(). Although there are
no other applications operating on the data (e.g., batch), I am running in a
clustered environment. Mode A of caching does not support clustering. Mode B
and C do. However, Mode C does not cache the entity. It flushes the entity
upon completion of the transaction.

I also would like to avoid putting data into HttpSession or a stateful
SessionBean while capturing data across multiple screens. It takes several
screens worth of capture before I want to persist the information. My
preference is to change the state of an EntityBean over several HTTP
Requests (Architecture is typical Servlet/JSP layer that talks to an EJB
layer using the delegate, session fa�ade and composite entity patterns.)
without persisting the EntityBean until the last screen of the unit of work
is done. Therefore, I set the beginning of the transaction during processing
of the first screen and commit upon the entry and validation of the last.

Mode B seems to be the best caching option. It performs an ejbLoad upon the
beginning of the transaction and caches state in memory during and after the
transaction is completed. What I am uncertain about is whether ejbLoad is
called when I execute a read-only method (i.e., get method) on the entity
outside the context of a transaction.

I really want a Mode A that is capable of clustering, or a Mode B where I
know there are no other applications operating on the data - I want a hybrid
of A & B, I think. I need to cluster, but I know I'm the only application
operating on any given column in the data store. The cloning process should
assure that my EntityBean can be cached without having to synchronize with
the data store ever. Seems to me this would be a common requirement.

I'm using WebSphere 4.02, if that matters. I'd like to hear others thoughts.

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

Reply via email to