>The concept of caching state *is* supported by every major EJB vendor. The
>problem is that this approach fails miserably in a clustered environment. I
>should add that this approach (even in a single ejb container scenario) is not
>very practical in *real-world* applications.
Actually I'm not so sure about this. When I am talking cached state I mean
shared cache state so that the data stays in memory between transactions
and can be re-accessed without doing an ejbLoad from the database at the
start of the transaction. As far as I know, Weblogic and Websphere do an
ejbLoad each time for exactly the reasons of a clustered environment
(Commit Option B/C) and because of the potential of external applications
updating the database outside of the container(s). We would need to have a
shared cache across clustered instances.
Commit Options B and C lead to local diamonds so that the same logical
entity bean could be represented by multiple instances - hence the
requirement to check/control concurrency at the DB level. Hey , isn't that
where we came in ? :-)
BTW does anyone put there have any experiences with Javlin ?
Cheers,
eddie
===========================================================================
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".
