Despite the fact that I completely disagree to all of your arguments,
this is the "apples-vs.-bananas" discussion I wanted to prevent.
It is just neither true that Java is slow always, nor that always JDBC
is faster than JPA. The real and complete answer is so complex that a
persistence beginner like him (and I assume him to be a persistence
beginner because otherwise he wouldn't try to replace JDBC by JPA or
vice versa) will not understand the real problems he runs in -- either
with JDBC or JPA. First one must understand that both target in totally
different directions, so there is no choice whether to do X or Y in the
same project: The project will dictate the technology anyways.
Regards
Markus
-----Original Message-----
From: Stephen Connolly [mailto:stephen.alan.connolly_at_gmail.com]
Sent: Mittwoch, 9. Juli 2008 23:28
To: users_at_glassfish.dev.java.net
Subject: Re: JPA: speed vs JDBC
There is a simple answer to your question...
JDBC can be optimized to be faster than JPA every time.
I can be certain of this because, ultimately, under the hood, all the
JPA providers are using JDBC...
The real question you have to ask is do you have the time to develop
and maintain your own object mapping layer and to do the optimizations
that are specific to your problem domain that will make your JDBC
based object mapping layer faster than one developed on the back of
JPA.
In my opinion, it is better to get something up and working first
before trying to optimize.
JPA uses POJOs, so if you need to do an optimization at a later point
that is above and beyond what you can do by tuning JPA (or by changing
the JPA provider) you should have not tied your code too much to JPA
as to prevent switching the hot spots to JDBC...
If you really care that much about performance you should not be
writing your app in Java anyway... write it in assembly to get every
processor cycle working for you... (oh but most JIT JVMs can optimize
your Java into faster native code than 99% of C++/C/assembly
developers could write, and developing in Java is quicker, so your
competitors will have got to market first)
-Stephen
On Wed, Jul 9, 2008 at 7:25 PM, Markus KARG <markus.karg_at_gmx.net> wrote:
> This is like comparing apples and bananas. The performance is
completely
> dependent on what you want to achieve and what actual providers you
are
> using. You should decide for a technology on a design or architecture
level.
> If you really want to decide on a performance level, you have not
understood
> what both are good for. Both are neither competitive, nor comparable.
> Besides that: Yes, I have performance benchmark results. But I will
not post
> them as they solely are taylored around my very own use cases, so they
are
> no good for you at all.
>
> You should post what you want to do, and then we can give you tips
what
> would be the better / faster / less-footprint technology for you.
>
> Regards
> Markus
>
> glassfish_at_javadesktop.org schrieb:
>>
>> Has anyone done some experiments on this topic? Looking forward to
know
>> the results.
>> [Message sent by forum member 'bobxu' (bobxu)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=285393
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>>
>
>
> --
> http://www.xing.com/go/invita/58469
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
For additional commands, e-mail: users-help_at_glassfish.dev.java.net