Hammoud,
as this is an enterprise computing forum, my assumption is a multi-tiered architecture (JDBC Driver must cross the LAN), as we all have to keep scalability in mind. As a result, the JPA cache is on the client side, while the JDBC / DBMS cache is on the server side. Assuming a JDBC-based JPA implementation, you will benefit from this double buffering (if you have luck, the object is in the client side JPA cache; if you have not so good luck, it is found in the server side JDBC / DBMS cache; if you have bad luck, you must go down to the hard disc). If you do JDBC on the client side, then there is no client cache (unless your particular driver vendor implemented one directly in the client side driver). So, a JPA query will return client side cached objects, while a JDBC query must forward the server side cached data over the LAN. In sum, you have far more LAN transport with JDBC than with JPA. Unless you have client and server on the same machine, what is untypical in Client-/Server computing (that's why it is called Client-/Server ;-) ).
For clustering, things are a bit more complex since there is a difference between pure JPA on the client side and JPA inside of the middle tier (used by Servlet and EJB). You should check e. g. GlassFish's clustering documentation for that. In core, there are three possible scenarios: (a) Do not inform anybody but check for changes revision numbers each time (no need to load object if revision number is unchanged), (b) Shared-All approach: Always write through into the shared disc, (c) Shared-Nothing approach: Inform all cluster nodes after each transaction. What type of cache sync gets used depends on the used product and configuration.
Have Fun
Markus
-----Original Message-----
From: glassfish_at_javadesktop.org [mailto:glassfish_at_javadesktop.org]
Sent: Donnerstag, 10. Juli 2008 17:12
To: users_at_glassfish.dev.java.net
Subject: Re: RE: Re: Re: JPA: speed vs JDBC
Hi Markus,
> If doing complex business tasks with lots of JOINS and 99% READ, then JPA will most of the time be faster than JDBC (thanks to the caching which prevents repeated SQL parsing and table scanning).
No experience with JPA, just JDBC on single server so far.
But thinking about your statement i ask me if this really can be true.
Because there is also an caching mechanism on database level, for example MySQL has the Query Cache.
If i think more about JPA Caching vs Database caching, i also consider how people do caching in bigger application.
Doing this application level with JPA means that the server must inform all server of the cluster on each transaction commit, that some cache objects must be removed or reloaded.
Think its better to cache on database level?
Hammoud
[Message sent by forum member 'hammoud' (hammoud)]
http://forums.java.net/jive/thread.jspa?messageID=285687
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
For additional commands, e-mail: users-help_at_glassfish.dev.java.net