Tom,
> I am still missing one piece of understanding due to my limited
> knowledge of SQLAnywhere. Since you are obviously quite a bit more
> expert than I, perhaps you can give me a quick lesson. You talk about
> mixing in the JConnect stuff. Can you give an example or two of how
> your SQLAnywherePlatform would have to be implemented differently in
> order to work with JConnect. Are there different types that should be
> used? Are there methods that would have to be implemented
> differently? I am just hoping to get a clearer view of how the
> JConnect stuff will cause issues with the "cleanness" of your platform.
Unfortunately Lance (who is demanding the jConnect support) did not yet
provide fixes for the list of broken tests caused by jConnect, so I
cannot tell you that. In fact, this discussion is a bit academic,
because in fact it is not clear whether the platform has to be changed,
or whether the broken tests are caused by bugs inside of jConnect. Let's
just wait what Lance's code looks like. I sent him the list of broken
tests yesterday.
>> (a) As you know, jConnect produces far more crashes in the
>> entity-persistence-tests. So you need more fixes. Since the platform
>> cannot find out what driver is running currently without losing some
>> quantum of time with each single query, jConnect fixes will
>> potentially lose time even when the platform is running on iAnywhere.
>> And that is a thing that makes me headache: I don't want to provide a
>> platform that is perfect and then put things into just because of
>> some doubtful backwards compatiblity -- if that compatibility fixes
>> create measurable performance drawbacks. :-(
> But in addition, there might arise technical reasons:
> Are we talking about time related to checking what driver is running?
> If so, I agree. We must determine what DatabasePlatform to use at
> bootstrap time and not have any need to check again (and definitely
> not do a driver check with each call)
Not only that. See, I want SQLAnywherePlatform run as fast as possible.
Any single optimization that I can think of is done in my implementation
(including micro optimizations like "final", removed unnecessary local
variables etc.). So it is not only unnecessary checking of the driver,
it also would be unnecessary redirection through some kind of "switch"
that routes every single call either into the "iAnywhere" direction or
in the "jConnect" direction. As fast as possible for me is NOT "as fast
as possible minus one IF".
Again, the cleanest solution would be to split platforms into drivers
and dbmss. Doing that, we had lots of problems solved (like using Merant
drivers with MS SQL and so on). In the past 20+ years of programming and
design, I always tried to find the cleanest solution, even if this means
that legacy users have to change something. I think the best politics is
to tell everyone the truth. Customers understand that cleaning up is
necessary, if you tell the truth about current code. The truth is, the
old platform was not a SQLAnywherePlatform. It was a
"The-Test-Are-Running-But-Actually-We-Did-Not-Care-About-SQLAynwhere-Not-Beeing-Related-To-Sybase-ASE-Platform".
If you tell REAL SQLAnyhwere users THAT explanation, they will
understand your decision of cleaning up. It's just one line to change
for them.
> I definitely agree we need to avoid performance drawbacks. As I
> mentioned above, as a SQLAnywhere amateur, I am hoping that someone
> can provide me with an example of how the SQLAnywherePlatform would
> perform worse if JConnect support was included in the current
> platform. (e.g. show me an example of a method that would be
> different for SQLAnywhere's shipped driver versus JConnect)
We have to wait for Lance's solution of the broken tests to see what the
change actually would imply. It was him that started the whole jConnect
discussion, so we should wait for his judgement, what code has to be
changed to actually solve the jConnect incompatibility.
> Although TopLink Essentials is a component of GlassFish, it is also
> the reference implementation for the JPA specification. It can
> certainly be used within GlassFish, but that can also be used with any
> container that is capable of using JPA. In fact, it is shipped as the
> default JPA implementation with a number of other containers including
> Oracle's Application Server, Spring, and TmaxSoft's container.
>
> Although there is a feature that allows us to explicitly detect the
> DatabasePlatform at runtime, it is also possible to explicitly specify
> it. See the toplink.target-database property in the following document:
>
> http://www.oracle.com/technology/products/ias/toplink/jpa/resources/toplink-jpa-extensions.html#TopLinkDBSessionAppServer
>
>
> This property allows the use of any of a list of predefined values or
> the use of the fully qualified DatabasePlatform class name. So...
> users can be using SQLAnywhere platform without it being automatically
> detected and could potentially override our detected settings when we
> do detect it.
Don't get me wrong, but I am solely a GlassFish contributor so I have a
completely different point of view. I'm not employed with Oracle
(Certainly I appreciate TopLinkEssentials beeing open sourced, as Oracle
appreciates my open source implementation of SQLAnyhwerePlatform
[otherwise we would not discuss this, actually]). I actually do not care
about Oracle customers or Spring users etc. (Sounds unfair, but actually
is the true sight of me not beeing in any relation to Oracle customers
or Spring users). If that people are using MY efforts for free (that's
what THEY actually do) then I expect them to spend one minute to change
their configuration from SQLAnyWherePlatform to
KeepItForBackwardsCompatibilityPlatform. Actually I spent six months of
my SPARE time to provide SQLAnywherePlatform (and MaxDBPlatform). So is
it too much to expect THEM to spend one minute each of their PAID time
to change their configuration?
>> (c) What problem should an existing user have reading the release
>> note "If you are using jConnect with SQLAnyhwere, then go into your
>> config and change from SQLAnyWhere to JConnectSQLAnywhere"? That fix
>> is done in one minute and we all would have a clean system.
> Our philosophy is to limit to the maximum extent possible the changes
> a user that is upgrading has to make.
One minute of time, from my point of view, is a maximum limitation
already. Going beyond that makes it nearly impossible to improve the
internal design and implementation of GlassFish in any direction. And my
target of a GlassFish contributor located in the corner of design and
implementation, is to provide A LOT of code contributions SOLELY
providing performance and stability fixes - a.k.a design and
implementation change request. Maybe we should think over that policy? I
hope that this forum is the right place to discuss this policy, since it
is essential to get knowledge and experience of
non-Sun-or-Oracle-employees into GlassFish. Or do you really want to
stay with design faults forever just to prevent users of spending one
minute of time?
> To make this kind of a change, in general, we require a clear
> demonstration of improved functionality in the product. Although, it
> is possible, the platform you are contributing, is "cleaner", that is
> an abstract concept rather than the kind of clear demonstration of
> improvement we look for. To provide a clear enough functionality
> improvement, we have to address JConnect. Otherwise, it is difficult
> to justify replacing the existing platform and we would be more
> inclined to check use a different name.
There is clear demonstration: It runs the FullRegressionTest suite with
just one error and one failure (the rest, I think / is already proven,
to be TopLink bugs). And the old one? So is improved performance,
cleaner design, and better support of the target platform no good reason
to improve an open source product that targets of beeing a REFERENCE to
other programmers of application servers?
>
>> (d) As Lance and I agreed upon, it might be possible to put the
>> jConnect fixes into a subclass of my platform so my platform will
>> learn to be jConnect compliant without cluttering or losing
>> performance. But this only works, if it is possible to ask for the
>> actual driver name ONCE at boot time (in fact, I don't know if this
>> is possible). If I need to ask for the driver name with each query,
>> the performance loss would not acceptable.
>>
>>
> I agree, performance is key. We definitely should not be checking the
> driver after bootstrap.
And we need to ensure that with any single method call, no time is spent
for things not needed by iAnywhere driver users. I'm sorry but I don't
like the idea that all iAnywhere driver users spend a single cpu clock
tick into things needed just for backwards compatibility needed ONLY
because some other users are not willing to spend one minute into
changing their configuration file.
Have Fun
Markus