I agree with most of what you said, most of the time. But I don't think I
quite said all of what you agreed with ;-).
I propose that a CMP middle-tier cache scheme would be useful *if and only
if* some of all of the following were true:
1. Cache management was configurable on an instance, class and overall
(default) basis
2. Joins could be done on the DBMS in SQL but results managed in the cache
3. Stored proc results (including sproc that return multiple resultsets)
could be managed in the cache
4. Database specific optimizations were used (IDENTITY vs SEQUENCE,
cascading referencial integrity)
5. The cache had a faster lookup scheme than an RDBMS and you (or the cache
manager) could choose either/or
6. The data being managed was either 90% singleton selects by primary key,
read only, or used optimistic transaction semantics (granular configuration
choices would help this)
7. Methods existed for chunky getters and setters as well as
method-call-per-field
8. The cache could be coherent (generally and with custom hooks for "special
occasions") among multiple server instances
Some EJB vendors proport to have some or all of these features through
vendor-specific (and non-portable) extensions to the EJB model. That's why I
was asking. The vanilla generalized CMP model says nothing about most of
this AFAIK.
In addition, I really wasn't being sarcastic when asking whether high
performance and scalability mattered most. Sometimes ease in development,
ease in maintanance, and portability across unlike servers/databases is
what's desired. Scalability can sometimes be acheived by buying more, faster
hardware. Best performance may be archieved by hand-coding one-off solutions
rather than a generalized architecture. OTOH, a highly tuned CMP-based
strategy may add complexity.
I appreciate your comments...
Bob Beauchemin
[EMAIL PROTECTED]
-----Original Message-----
From: Chip Wilson [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 20, 2000 10:41 PM
To: [EMAIL PROTECTED]
Subject: Re: O/R Mapping Tools
I completely agree. In an EJB environment, the dB should manage the cache.
Any
cache above that level is at best useless and at worst problematic.
I have yet to find a CMP implementation that is useful/useable. I'm not
sure
that I even want or need CMP.
"Beauchemin, Bob" wrote:
> As long as the subject has been brought up, what is anyone's opinion on
> Persistence Power Tier? They make some amazing claims and seem to have
> addressed most of the CMP concerns like facade pattern, data chunking,
> stored procedure utilization, relationships, cache management and
failover.
> Opinions? War stories? The patent for parts of the architecture is on file
> and accessible through the web and makes interesting reading.
>
> IMHO, CMP entity beans don't seem all that useful without a cache
> architecture to make it worthwhile to shuttle all that data back and forth
> between database and middle tier, with the gobs of network roundtrips that
> implies. Unless the EJB container has a better SQL engine than the RDBMS
or
> 90% of the access is row-at-a-time (and, pre-relationship support,
> table-at-a-time). Am I missing something obvious? Or are performance and
> scalability not major concerns?
>
> Bob Beauchemin
> [EMAIL PROTECTED]
>
> -----Original Message-----
> From: Chip Wilson [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, December 20, 2000 1:48 PM
> To: [EMAIL PROTECTED]
> Subject: Re: O/R Mapping Tools
>
> I've used it on three different projects. I don't have the ability to
> support all the following claims right now - so take them for what they
are;
> unsupported opinions. TOPLink is bloated, overly-complex, and
innapropriate
> for an EJB architecture. The transaction API and implementation have to
be
> shoe-horned into a JTA environment. It doesn't support 2PC, or at least
it
> didn't a year ago. Debugging problems is a nightmare. Developing and
> maintaining mappings takes longer than writing individual broker/mapper
> classes for each persistent object. The ramp-up time for developers is
> extremely long. TOPLink is really, really slow. The cache is useless in
an
> EJB environment. TOPLink is really expensive.
>
> I have written, helped write, designed and used countless O/R frameworks
in
> C++, Smalltalk and Java. I even helped develop a commercial competitor to
> TOPLink, but it is no longer supported.
>
> In an EJB environment, I favor a minimalistic O/R framework with
> broker/mapper classes that execute JDBC calls and map between the schema
and
> the domain model. Entity beans access the persistence framework through a
> facade. I typically prefer to hard-code the mapping logic, as this is the
> easiest to develop, learn and maintain. If you must do some sort of
> meta-data-based mapper, keep it simple and allow the ability to do it
> manually in specific brokers. A simple framework like this can be
designed,
> implemented and tested (minus all the individual broker classes) in 40
> man-hours.
>
> >From: "B. Flaumenhaft" <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> >Subject: Re: O/R Mapping Tools
> >Date: Wed, 20 Dec 2000 11:55:20 -0800
> >
> >
> >Can you give us some details? I'd be very interested to learn more. I
> >looked at TOPLink some time ago and was very impressed by its feature
> >set and customizability. It was simply too expensive, and I had some
> >doubts about performance and the runtime model.
> >
> >Why should we run away?
> >
> >Thanks,
> >Ben Flaumenhaft
> >
> >At 8:13 AM -0600 12/20/00, Chip Wilson wrote:
> >>Run away from TOPLink as fast as you can. Run far away.
> >>
> >>>From: Thomas B�kamp <[EMAIL PROTECTED]>
> >>>Reply-To: A mailing list for Enterprise JavaBeans development
> >>><[EMAIL PROTECTED]>
> >>>To: [EMAIL PROTECTED]
> >>>Subject: O/R Mapping Tools
> >>>Date: Tue, 19 Dec 2000 23:37:50 -0800
> >>>
> >>>Hi,
> >>>
> >>>Parts of my current work is to evaluate O/R Mapping Tools products. Is
> >>>there
> >>>such a thing a report to study different O/R Mapping Tools . Currently
we
> >>>are looking at Cocobase and Toplink. Can somebody help with the
following
> >>>questions:
> >>>
> >>>- Anybody know about Cccobase or Toplink the quality and Performance?
> >>>- Any other O/R Mappers worth evaluate? Especially we would like to
know
> >>>if
> >>>there is a product that the C++-part of the project can use too.
> >>>
> >>>Thanks in advance
> >>>
> >>>Thomas.
> >>>
>
>>>_________________________________________________________________________
> >>>Get Your Private, Free E-mail from MSN Hotmail at
http://www.hotmail.com.
> >>>
>
>>>=========================================================================
> ==
> >>>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".
> >>>
> >>
> >>_________________________________________________________________
> >>Get your FREE download of MSN Explorer at http://explorer.msn.com
> >>
>
>>==========================================================================
> =
> >>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".
> >
> >
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
>
>
===========================================================================
> 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".
>
>
===========================================================================
> 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".
===========================================================================
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".
===========================================================================
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".
