Like I said after the quotes,
> "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!"
But even that argument is now moot, for Jonathan and I have settled our
differences offline (He invited me over and feted my with wine and beer ;-))
Gene
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Rick Hansen
Sent: Tuesday, September 12, 2000 1:27 PM
To: [EMAIL PROTECTED]
Subject: Re: FatKey Pattern...
Most of your quotes seem to have nothing to do with your fatkey pattern.
Rick Hansen
>-----Original Message-----
>From: Gene Chuang [mailto:[EMAIL PROTECTED]]
>Sent: Monday, September 11, 2000 2:33 PM
>To: [EMAIL PROTECTED]
>Subject: Re: FatKey Pattern...
>
>
>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".
>
>===============================================================
>============
>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".
