MARK HAPNER wrote:
>
> Thanks to Rickard for his analysis of Roger's article.
Saves me the bother of wasting my time reading it :-)
> Roger's contention that EJB Entity and Stateful Session components are
> not efficient enough for enterprise use and the 'analysis' that supports
> that contention unfortunately has no basis in fact.
I agree that EJB components are efficient enough for enterprise use.
> The major overhead in most components is the database lookup and update.
> MTS components don't provide any optimization of this function. They are
> just harder to program because developers are forced to use stateless
> functions. The EJB entity model does not require any extra database
> overhead and since the EJB container understands what the developer is
> trying to achieve it can help optimize the work.
I believe that Microsoft's IMDB (in-memory database) is designed to
alleviate such problems. As I understand it, it is a write-through
transactional cache. This would appear to fall into the category of
an 'optimization'. IMDB can deliver many of the same benefits as
EJB 1.1 Commit Option A.
> I'm not an expert in COM or COM+ but it is my impression that there is
> no simple way to cache the database data for a business component even
> across multiple method calls within the same transaction. With EJB, both
> Entities and Sessions get this for free (from the developers
> perspective). In the multi-method per transaction scenario I would
> expect MTS objects to make many more database requests than the
> equivalent EJB components.
It appears that you have forgotten that MTS component instances can retain
conversational state for the lifetime of a transaction. They are not
necessarily stateless, if you choose you can have them "stateful within
a transaction, stateless between transactions". Even EJB (version 0.4) was
once exactly like this. I still have a copy of the spec!
> If Roger were more observant he would see that the current MTS 'object'
> model is woefully outdated and is based on assumptions about
> 'efficiency' that might have been true in the '70s but are no longer
> considered relevant by the industry.
That is a bit harsh. Would you suggest that the designers of EJB 0.4 were
not very observent, or were 25 years out of touch with relevant object models?
Don't get me wrong, I like EJB! But from the experience of implementing both
MTS, EJB 0.4 and EJB 1.0/1.1 semantics in a single product, I can tell you
that COM+ with IMDB has the potential to deliver similar scalability to even
quite good EJB implementations (on the same platform and hardware). The key
wins with EJB in my opinion are:
(1) Less coding is required with stateful session beans and CMP entity beans
than would be required with the latest COM+ options.
(2) It offers more opportunities for clever cache management, such as something
between commit options A & B (using some 'cheap' DB operation like a
timestamp check to determine if cached state is stale).
________________________________________________________________________________
Evan Ireland Sybase EA Server Engineering [EMAIL PROTECTED]
Wellington - New Zealand +64 4 934-5856
===========================================================================
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".
