Hi Jonathan,
Well, I think the people have spoken... here are snippits from what various
responses this thread:
****************************************************************************
******
"(FatKey) approach is interesting, and although it is arguably
(and perhaps provably) not portable, it would appear to be of considerable
practical use. Once EJB servers have matured to the point that most of them
have powerful caching options (at least for CMP), it would be less
interesting."
Evan Ireland
"I agree whole-heartedly with Gene on this point. I totally despise a vendor
taking options away from me on the assumption that I am too stupid to
properly
implement a piece of code."
Tim Endres
"Cool pattern otherwise, we kind of like it here :-)"
Cedric Beaust
"yeah, I also did the same thing."
Ana Bhattacharyya
"Who out there is still on the Advanced Java list? Nobody here
I bet. This list is the replacement I'm afraid."
Curt Smith
"Jon, would it not have been more powerful to defer to "user provided
method" if
available else use internal comparison?"
Deepak Srinivasan
"I enjoyed reading through this thread. It had some very good technical
content."
Bryan Cooper
"So you don't trust the developers. This has been a sore point with me over
the many years I have been a developer. The creators of the tool I need to
use often assume they are smarter than I am and therefore restrict my
ability to get real work done.":
Bob Schultz
****************************************************************************
******
The point I'm trying to drive here is not that my pattern is viable, but
rather bean developers are quite sophisticated and perhaps deserver a little
more respect than what you are giving us! EJB is in its nascent stages and
its growth benefits greatly from container as well as bean developers, a
sort of parallel evolution which ultimately will converge into a final
product.
Correct me if I'm wrong, but from what I gather from your responses, Inprise
seems to take the "Keep All of the advanced technical issues on the
container side" stance, which caters greatly to those new to EJB or Java
development. However as you can see by the responses from the denizens of
this board, WE WANT TO BE INVOLVED!
I hope Inprise takes notice; otherwise it will continue to lose valuable
market share of advanced programmers to vendors like Weblogic and Websphere!
Gene Chuang
Teach the world... Join Kiko!
<http://www.kiko.com/profile/join.jsp?refcode=TAF-gchuang>
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Jonathan K. Weedon
Sent: Monday, September 11, 2000 11:25 AM
To: [EMAIL PROTECTED]
Subject: Re: FatKey Pattern...
Gene,
I am troubled with what you are doing. To me, you have built a
workaround for the limitations of one vendor on top of a workaround
for the limitations of another vendor. I think you are building
a house of cards! Instead, I think it makes sense to go back to
the original problem, and see if there is not a simpler solution.
The basic problem is that you are using Bean Managed Persistence.
I suspect that you are using BMP to workaround the limitations of
the CMP engine provided by your vendor. Have you really looked at
other options? There are two options I would look at. The first
option is to see if there is an AppServer vendor which provides a CMP
engine which can handle your beans using CMP, properly. If you
have reasons that you cannot switch AppServer vendors, then there
are a number of O/R vendors, such as CocoBase, who provide plugins
with comprehensive CMP support, and which are integrated with most
of the commercial AppServers.
<vendor>
Basically, the reason that I can find (IMO) significant flaws in
your FatKey patterns is that I have implemented this optimization
(correctly) in our CMP engine. Along with that, we provide the
following O/R capabilities:
* Tuned updates: we (optionally) issue an update for exactly the
fields modified (or none, if the bean was unmodified), not all the
CMP fields. (And I should point out that this is done without
using "hashing", as is extremely fast.)
* Verified updates: we (optionally) issue an update which verifies
the values of the CMP fields from the start of the transaction,
which addresses issues with optimistic concurrency.
* Relationships: we support one-to-one, one-to-many and many-to-
many relationships, all using the underlying database foreign
keys.
* Dependent object: details can be stored in the master's table,
or in a separate table.
* Mapping to multiple tables: an entity bean can be mapped to any
number of tables (possibly in different databases).
* Primary key generation: we support both portable primary key
generation, as well as Oracle sequence-number-based and Sybase/Microsoft
identity-based variants.
* DD configurable loading of state in finder methods (this is your
optimization).
* Schema creation from beans.
* Bean creation from schema.
* Beyond the above "big" features, there are lots of little feature,
like batching of updates, recycling of prepared statements, etc.
which all help to improve the overall performance.
</vendor>
Basically, I would be very surprised if you application could not
be run using CMP on our engine, or on one of the other commercial
O/R plugins. And, I would be very surprised if it did not run
faster. Thus, I have difficulty agreeing that your complex FatKey
pattern is really well motivated. Any decent CMP engine will already
have implemented your optimization, and dozens of others. If you need
speed, you need a decent CMP engine. If you need O/R capabilities,
you need a decent CMP engine. Why bother rolling your own? (And
doing so incorrectly, I might add.)
-jkw
Gene Chuang wrote:
>
> Hi Jonathan,
>
> Actually yesturday I thought up of a trivial modification to FatKey that
may
> make it compatible with Inprise, as well as any other container that
hashes
> primary keys using serialization: Make FatKey's reference to the data
> container 'transient'!
>
> Gene Chuang
> Teach the world... Join Kiko!
> <http://www.kiko.com/profile/join.jsp?refcode=TAF-gchuang>
===========================================================================
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".
