Subject: Persistence with JDBC ??? 2005-10-10 - By Chris Harrison
Back
Hand coded (& bug free) JDBC is almost always faster than any OR framework.
OR frameworks are popular, but does that make it good? I'm open minded about
OR mapping. EJB CMP and even JDBC in BMP is the standard & is very well tested
and proven technology, can anyone sight an example of the other OR mappings
(say hibernate) being used successfully in a very large project? (Please dont
refer to popular websites, as thats not a good comparison, I'd prefer an
example of a bank using it or other large enterprise). What was the experience
like?
Ch.
-- --Original Message-- --
From: An interest list for Sun Java Center J2EE Pattern Catalog
[mailto:J2EEPATTERNS-INTEREST@(protected)]On Behalf Of Nicholas Wee
Sent: Tuesday, 11 October 2005 10:17 AM
To: J2EEPATTERNS-INTEREST@(protected)
Subject: Re: Persistence with JDBC ???
JDO and Hibernate are Object-to-Relation Frameworks.
That is, it does the
marshalling of data from your objects to relational
databases (by
translating object information into JDBC calls and
vice-versa). Of course
this will mean some level of overheads when using
these frameworks compared
to using JDBC directly. However, with JDBC it means
that developers are
doing that translation betwen Objects to Relational DB
by coding the
marshalling logic (i.e. Object data to JDBC statements
and from Resultsets
to Object). As such, there is usually more 'bugs'
associated with
applications that are coded with JDBC as compared to
applications that are
coded using one of the OR frameworks mentioned
earlier. General philosophy
applies here: more you code more bugs you introduce.
Thus, as a best practice for developing large and
complex applications, you
would want to use an OR framework, unless raw
performance is extremely
critical (over maintainability and overall system
robustness). Usually,
there would be a mixed usage of both OR framework and
direct JDBC
transactions - where the OR framework is used for most
of the functionality
of the application and only those few that require raw
performance to use
direct JDBC (and these are usually scrutinized more
closely to ensure code
quality).
Also, with most J2EE servers, connections to the
database is a managed
resource and for performance purposes, a number of
connections are
pre-established when the J2EE server startups and
reused throughout the
lifecycle of the J2EE process. This is also a
mechanism to ensure that your
database is not overwhelmed with sudden connection
requests.
In regard to support to cache management, it depends
on 'what' that are
'read-only' information verse 'what' are 'read-write'.
Normally, there
would be a rather large set of information that are
'read-only in general'.
In these cases, we would create a system-wide object
cache and cache such
information to reduce the amount of actual DB
transactions for information
read. You would need to consider how-and-when object
cached would be
removed from the cache and how information in the
cache wold be updated if
there are changes to it and synchronising the
information change with you DB
transaction.
Nicholas
-- --Original Message-- --
From: An interest list for Sun Java Center J2EE
Pattern Catalog
[mailto:J2EEPATTERNS-INTEREST@(protected)] On Behalf
Of Juan Carlos
Sent: 11 October 2005 00:51
To: J2EEPATTERNS-INTEREST@(protected)
Subject: Persistence with JDBC ???
Hi everybody, I'm migrating a legacy system from
pl/sql to J2EE.
Initially i had to use an implementation of JDO, but
after trying to
translate lots of query without getting a good
performance and, in many
cases, being almost impossible to translate them, we
are planning to use
other persistence system. Some people suggested me to
use JDBC and call
directly stored functions or execute statements.
I've tried it and it performs much faster than with
JDO. I think it's
normal, since now we are avoiding to create the
objects and simplifying
considerably the number of queries (JDO generates
lots).
Although JDBC is faster, I know that there are some
issues I should consider
before adopting it. The one that more worries me is
the cache management.
The system manages lots of data and users, and same
queries are invoked once
and other.
Do you think that JDBC is a good solution? Is that
enough for a big
web-based system?
I know that I could use Hibernate but initially the
chiefs didn't want to
use free software for persistence, since is a very
critical system and they
always want to have some comercial ''support''..
Another thing is that the system is based only in
servlets (with Struts) and
doesn't use any kind of EJB.
Thanks in advance!!
===================================================================Companion
Site: http://www.corej2eepatterns.com J2EE
BluePrints:
http://java.sun.com/blueprints/corej2eepatterns
List Archive:
http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST"
to
listserv@(protected)
__ ____ ____ ____ ____ ____ ______
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
===================================================================Companion
Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
The information transmitted is intended only for the person or entity to which
it is addressed and may contain confidential and/or privileged material. Any
review, retransmission, dissemination or other use of, or taking of any action
in reliance upon, this information by persons or entities other than the
intended recipient is prohibited. If you received this in error, please contact
the sender and permanently delete the material from your computer system. We
cannot guarantee that this e-mail is virus-free. You should scan attachments
with the latest virus scan before opening. We will not be liable for any loss,
cost or damage of any kind whatsoever caused by any receipt or use of this e
-mail and attachments.
===================================================================Companion
Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
|
|
