Just to make sure I've got things straight:
CMP is the process through which the cached state of a bean is synched
with the database by the container at appropriate times. I think the
optimizations you speak of are more of a vendor optimization independent of
whether the bean is using CMP or not.
Am I right?
Jon
I doubt if you can make use of the optimizations/caching supported by an EJB server
in all scenarios with a BMP which you would otherwise get from the EJB server in a CMP.
Or atleast AFAIK it is a great responsiblity on the bean developer using BMP
If I understand it right EJB server provdes this "caching" which the Container would
make use of in CMP.
A BMP can make use of the "caching" optmization techniques that a EJB server provides
if it involves reading without any additional responsibilty.
On the other hand if a BMP developer want to make any write/updates from this EJBean,
now EJBean developer must make sure that this changes are also reflected in the
"caching" - since EJBean developer is the one who takes care of "ejbStore" not the
container in a BMP.
Asuming that there would be a need on the BMP developer to be able to have
write/update on an EJB server and reflect it in the "caching" layer.How does EJB
server take care of synchronizing it's cache with any updates/writes from a BMP?
I guess WebLogic had support for caching. Any insights on their caching takes care of
this?
This raises a very good questions,
Do App Server's need to provide a standard/minimal layer of "caching" service so that
bean developers can have a common format to deal with when they wish to make use of
this "caching" themselves, as in BMP.
Shouldn't support for "caching" made mandatory in all app servers. This layer I guess
would be used by any "specialized" container who want to plug in to an EJB-Server and
want to make use of "caching" service on the EJB server an higher level. "Caching" no
doubt at a minimal is required in EJB framework.
I guess a BM developer can also make use of this same higer level API to make use of
this "caching" for his code. I definitely feel that there might be need for deveopers
to have the flexibility in certain cases. Depending on the containers for certain
specific caching/optimization scenarios ties an expert programmer to come up with
better alternatives.
As far the actual implemtation of the caching algorithm at an lower level is
concerned it can be very vendor specific. I hope this doesn't sound like a crazy idea.
This is again IMHO. Some of the API now provided by the EJB server like
concurrency/threading/caching must be made available to EJBean developers like
"system" libraries in a traditional OS. So that application developers (using EJB) can
have the flexibily to make certain wise choices as the situatin demands adhering to
the EJB framework.
I am really looking forward to some very interesting opinions from EJB-experts.
Thanks,
Nishi.
===========================================================================
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".
