Hi,
Michael wrote:
>> Geoff wrote:
>> Doesn't this mean that the EJB specification should be
>> changed so that such behaviour can be controlled by us through a
>> standard API which all vendors support consistently?
>You just found a major problem of the EJB spec. It leaves too much room
>for guessing.
IMHO there is a need for the EJB specification to allow sub-classing of
vendor container classes or to be able to over-ride standard
container APIs to control the behaviour for specific types of EJBs.
This is the main area where vendors have freedom to implement their own
features and this is the main cause of incompatibility between vendors.
If, for example, static-data EJBs could be permanently cached
in memory for faster access, without the
overhead of store, passivation, activation and load,
then read-only data would be accessed faster and with less overheads.
Hopefully the Container Extensions proposed in the EJB 2.0 features
on web page http://java.sun.com/aboutJava/communityprocess/jsr/jsr_019_ejb2.html
will allow better control over automatic passivation, rather than
setting timeout limits as done by some vendors.
BTW the Java Data Objects proposal on web page
http://java.sun.com/aboutJava/communityprocess/jsr/jsr_012_dataobj.html
suggests that persistence will be transparent and in an OO manner.
But, once again, what support is there going to be for customization
for particular types of EJBs? Hopefully it will also be possible
using JDO to make some types of objects memory-resident on a class basis.
Geoff
===========================================================================
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".
