Yes Evan,
Option B will be the choice for scalable solution. As you have mentioned about caching
with option B, underlying architecture in the application server can maintain the
cached state (state object)of the bean separately and all the concurrent beans can
load (through ejbLoad) from the state object rather than from the database.
The issue comes when one of the client has modified the bean and committed the
changes. In that case the state object of the bean should be updated so that the new
clients can get the newly commited state of the bean from the cache.
Note that FrontierSuite from ObjectFrontier provides such a runtime solution for all
application servers in a portable way.
===========================================================================
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".
