Hi Rick,
Well why depend on peoples comments -- maybe it can be tried out and I am
pretty sure it is going to give a real good performance, at least it gave
for me. Well I got the idea from BEA Commerce Servers "Samrt key" pattern --
well that "smart key" is pretty different from what Gene and I had done but
my idea was from there.
thanks
Ana
-----Original Message-----
From: Rick Hansen [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 12, 2000 4: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".
STATEMENT OF CONFIDENTIALITY. The information contained in this electronic
message and any attachments to this message are intended for the exclusive
use of the addressee(s) and may contain confidential or privileged
information. If you are not the intended recipient, please notify
USPowerSolutions Corporation immediately at (617) 547-3800, or at
[EMAIL PROTECTED], and destroy all copies of this message and any
attachments.
===========================================================================
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".
