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".
