I had developed an OR framework (prior to OR
frameworks like hibernate, EJB
CMP, etc) and use it for a system that manages
shipping containers and port
activites over serveral countries from a central data
center over the
Internet.
Main advantage I felt about using the OR framework is
that I don't have
every developer touching the database (and at that
time, good Java
Developers are hard to come by). So I was able to
ensure that database
connections are all properly closed after it was used
(a major cause of
resource leaks in a J2EE environment). I could
enforced (thru the OR
framework) optimistic locking to data changes (verses
no locking by some
developers). Also, I could easily support different
types of entity classes
for different countries without havng bloating the
classes with unnecessary
attributes and operations.
Yes, using an OR framework, even mine, did cause some
performance lost. But
still did well enough to support 1 million container
based transactions per
year well enough. Also bear in mind that JDBC is only
as fast as how well
the code written to use it. A bad programmer (which I
have encountered too
many times) can write very inefficient JDBC and,
worst, SQL statements that
impacts not only the Application's performance but
cause unnecessary load to
the Database. Good OR frameworks usually compensate
for the extra
processing (thus poorer performance) with other
techniques to optimize the
query to the database (such as object caching to avoid
calling the database
unnecessarily), and implement some form of best
practices when dealing with
the database.
Again, as mentioned earlier, I would adopt a
combination solution and allow
transactions that have very high volumes and are
performance sensitive to
use JDBC directly. For example, recording audit logs
to the
database...hiding behind a logging framework, the logs
are stored directly
to the database via JDBC, not the OR framework.
Nicholas
-----Original Message-----
From: An interest list for Sun Java Center J2EE
Pattern Catalog
[mailto:J2EEPATTERNS-INTEREST@(protected)
Of Chris Harrison
Sent: 11 October 2005 08:32
To: J2EEPATTERNS-INTEREST@(protected)
Subject: Re: Persistence with JDBC ???
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)
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)
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)
__________________________________
Start your day with Yahoo! - Make it your home page!
http://www.yahoo.com/r/hs
====================================================================
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)
