>> > From: Chuck Zheng [mailto:[EMAIL PROTECTED]]
>> >
>> > Hi Kevin,
>> >
>> > Which version of TopLink do you use? Their version 2 & Weblogic version
>>
>>We're using 1.1. Maybe 2.0 is better. I have no idea.
2.0 is significantly improved over 1.1 in many areas.
>> > broucher looks impressive What's the fundamental flaw of their design
>>you have found?
>>
>>Its inability to use a proxy/broker object to map another object is a
>>fundamental
>>flaw. It forces the creation of mapping methods on domain objects. The
>>value-holder scheme they provide is not really useful for basically the
>>same reasons; inflexibility and intrusion.
If I understand what you're saying here, both points are essentially the
same. You would like to have truly transparent proxies with indirection, so
that if an Employee holds a reference to an Address, we can defer reading
that address but leave in its place a transparent forwarder.
So would we, and we consider the requirement to use ValueHolders a
significant intrusion that we would get rid of if we could. Unfortunately,
all of the currently available (non-EJB, see below) alternatives are, in
our opinion, worse. Java does not currently allow the use of a general
forwarder such as you can get with mechanism's like Smalltalk's
"doesNotUnderstand: handlers" or C++'s "smart pointers". The current
options in Java are essentially
- code generation: we could generate code for your domain classes, which
some products do, but that's extremely intrusive and inflexible.
- "transparently" modifying code: This breaks down into several cases. We
could post-process source code, which adds an extra step (or more) to the
development process, is painful for debugging, and is not easy to do
correctly in all cases. We could post-process bytecodes after compilation,
either as an explicit step or by intercepting the class loading process.
This solves some of the problems of post-processing, but not all, and still
risks interfering with other tools.
- a custom VM which adds appropriate hooks: not a realistic option.
- an explicit mechanism that forces the users to add the layer of
indirection.
We consider an explicit mechanism the least bad of these options. I'm not
sure why you would call this inflexible. Since it's explicitly coded, the
user has complete control over it, including wrapping it in other
mechanisms for (e.g. for access control) and not using it at all.
All of this discussion is in the context of "vanilla" TOPLink for Java. The
EJB case changes things significantly. For one thing, there's already a
layer of indirection in place, in the form of the EJBObject. Because we're
integrating with the server, we can hook into the notification available at
the EJBObject level and avoid the need for any additional proxying.
>>
>> > What are the limitations?
>>
>>The only collection it supports is Vector. The least it could do is
>support
>>Enumeration.
This was a limitation in version 1.0. Just supporting Enumeration (i.e.
hiding the actual type from TOPLink) would not have been particularly
useful because TOPLink has to be able to create these collections when
reading objects. Unless you just wanted enumerations of vectors, we would
need some kind of collection policy which is user-extensible.
Version 2.0 has such a collection policy. It supports all of the JDK 1.2
collections out of the box, and is user-extensible for others.
>>The lack of support for aggregate inheritance mappings has caused us to
>>have mapping methods in base classes. We have some base classes that have
>>dozens of extra methods because of this.
To clarify. In TOPLink we use the term "aggregate mappings" to refer to
storing more than one object in a single row. For example, an Employee may
hold an EmploymentPeriod object, which doesn't have its own table, but
rather is stored "inlined" in the EMPLOYEE table. In an EJB case, this
might be what the 1.1 spec refers to as a "dependent object".
TOPLink supports aggregate objects, but currently does not allow subclasses
to be embedded into the table with them. This is a limitation, but I would
consider it relatively minor in comparison to the total feature set that
TOPLink is providing.
>>Also, in 1.1, there is no way to query into an inheritance hierarchy. This
>>means that you can only search on attributes that appear in the base class.
To clarify. When querying for a superclass, you cannot query on attributes
of a subclass. e.g. Suppose that we have a superclass A with attribute a,
and a subclass B with attribute b. You can write a query which is
equivalent in Java code to
A anA;
...
if (anA.a = 12) ...
If you're querying for the subclass, you can access attributes of the
subclass, so you can also write a query equivalent to
B aB;
...
if (aB.b = anAccount) ...
or you can write
B aB;
if((aB.a = 12) && (aB.b = anAccount)) ...
what you CANNOT do is something of the form
A anA;
...
if ((anA.a = 12) && (
(!anA instanceof B) || ((anA instanceof B) && (((B)anA).b = anAccount)))))
....
That is, if it's an instance of B, is the attribute b of some value, but if
it's not an instance of B, ignore that condition.
Again, while this is conceivably useful, and is something we are
considering, I would consider it a limited case, and not one which
justifies the statement that you "cannot query into an inheritance hierarchy".
(Here's what this would actually look like as a TOPLink query for the third
valid case)
ExpressionBuilder bBuilder = new ExpressionBuilder();
session.readAllObjects(B.class,
bBuilder.get("a").equal(12).and(bBuilder.get("b").equal(anAccount));
>>I have no idea. All I can say is that, in some tests we ran, we found
>TOPLink
>>to be roughly twice as slow as hand written JDBC. I believe TOPLink's
>>documents
>>back up this finding.
No, they do not.
TOPLink clearly imposes some overhead, and performance of this kind of
system is difficult to measure in a fully general way. Our estimates for
low-level operations are that we impose an overhead in the neighbourhood of
20% above basic JDBC operations. This can vary dramatically in either
direction depending what kind of operations you're doing. For example, date
printing in Java is very slow. If you do not have parameter binding
enabled, and you are doing date operations, you will see a much greater
performance hit.
On the other hand, in many cases TOPLink can perform much *better* than
plain JDBC. The greatest overhead in database operations is typically the
cost of a database round-trip. Since TOPLink has much more information
about the overall program, it can do very significant optimization of these
round-trips. For example, TOPLink does minimal writes, only writing objects
that have actually changed. We also have features like batch/joined reading
and batch writing which can greatly reduce the number of database round trips.
Whether a particular transaction rate is achievable will depend enormously
on the database, the drivers, the servers, what configuration you're using,
and how complex the transactions are. We do have many people using our
product successfully, three examples (US West, First Union, Glaxo-Wellcome)
can be found at
http://www.objectpeople.com/toplink/Customers/
In general, what we would recommend for performance evaluation is to get an
eval version, which you can do for free from our web site at
http://www.objectpeople.com and try it out. (Note that this is the
"vanilla" version. The WebLogic integration is currently in beta and not
yet generally available). Try it out on some reasonable-sized example and
see if it's suitable for your needs.
--
Alan Knight [EMAIL PROTECTED]
The Object People http://www.objectpeople.com
613.225.8812(v) 613.225.5943(f)
===========================================================================
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".
