LOGO - xTreme Software

streakconvertingSoftware and s/w Development

Dec 13, 2013 (3 years and 5 months ago)

76 views

LOGO

LOGO

Contents

Performance tuning

Best practice

Why Hibernate?

www.key2.
it


Key objectives

LOGO

Acronyms

&
Definitions


ORM: Object
Relational

Mapping


POJO:
Plain

Old

Java
Object


JTA: Java
Transaction

API


JPA: Java
Persistence

API




www.key2.
it


LOGO

Key objectives


Continuity with the development model used
in
EuropCar


Allows clear separation of business logic from
data access logic


Hibernate development model’s allow to start
together database porting and development


Different layers of cache to maximize
performance


Ability to work on multiple configuration
parameters to analyse and improve
performance


www.key2.
it


LOGO


Translate relational world (tables, views,
etc.) in the corresponding Java objects


Free developers to write and handle SQL
code into Java sources


It’s independent from underlying RDBMS


Standard
-

adopted in JEE 5 (JPA)


Improve productivity


fast TTM


www.key2.
it


Hibernate

LOGO

Before: JDBC + SQL


Business classes mixes Java and SQL code


Any change to tables structure require
code maintenance of all query to reflect
new
structure


No performance optimizations = no native
sql

optimization, no caching, no statistics

www.key2.
it


LOGO

Solution: Hibernate


A change to a table structure, is reflected, in
the modify of instance field of the POJO.
Query is automatically generated at run
-
time


Query are checked at compile time if used
load/get methods and Criteria query


No more need to mix SQL with Java


Many architectural aspect can be automated
and left handled by application server
(connections release, transactions handling,
etc…)

www.key2.
it


LOGO

BEST PRACTICE

Avoiding common mistakes

www.key2.
it


LOGO

Best practice


DB Design


Database design with software engineering
standards


Numeric PK: can speed up search and remove
elements in Java collections. Is more compatible
with Hibernate cascade automation


Avoid use of stored procedure to insert or update
data: hibernate cache can’t properly function if a
stored procedure modify data that already are in
Hibernate session’s


Relations many
-
to
-
many: in association tables
must be present only the two primary key of the
related tables



LOGO

Best
practice

-

Development


Development can be speed up using two main teams: one
for database migration and one for application code


Using component: many entity share set of common data
(for ex:
insert_date



delete_date



insert_user



etc…)
this kind of fields can be grouped into shared, reusable
components


In methods avoid of use of get() method. Use instead
load() if you don't need lock it


Inheritance mapping strategy: if correctly implemented
avoid programmer to make more than one query to access
a multiple table. This strategy handle automatically
discriminator fields during insert phase


Separation of read
-
only method or entity. In this way
access to read
-
only function don’t require instantiation of
transactions

LOGO

Best
Practice

-

Tuning


Hibernate use JEE connection pool. The pool is
handled by the underlying application server


Fetch of collections (table relations) with lazy
-
loading or join


First level cache: associates object loaded from
DB into
H
ibernate session


Second level cache with many configuration
possibilities (read / read
-
write/ etc.) Can work
with
JBoss

and enable clustering support


Query cache: for query often executed (ex: to fill
combo boxes, dynamic menu, etc…)


Statistics



www.key2.
it


LOGO

Connection Pool


When the application server start open a
number of connections to database (pool)


Pool size is handled by application server
that remove or add connections as needed


Configuration of the pool define start
connection number and increase size


Open connections with this method reduce
application response
-
delay respect to old
-
style “open and close connection
-
by
request”

www.key2.
it


LOGO

Associations: Join or Lazy


JOIN fetch mode: on loading of a parent object hibernate
load related objects with JOIN


Benefit: only one DB access for parent and its child


Drawbacks: if related objects are not needed they will be also
loaded


Lazy fetch mode: child objects are loaded only when
relation are navigated


Benefit: not needed objects are not loaded


Drawbacks: if related objects are needed N+1 query by primary
key are executed


Q: Best solution?


A: Depends on use case!


Change

fetch

mode

is

simple!

Only

to

change

configuration

is

needed
.

No

code

change

is

required

www.key2.
it


LOGO

First Level Cache


Holds

entity

loaded

from
db

so
its

loaded

one

time
only

for session


Optimize

entity

access

to
db

so
insert
/update/delete are made in
optimized

way.
Not

all

Java
instructions

are
converted

in SQL

www.key2.
it


LOGO

Second Level Cache


Hold objects loaded from database and share
them between sessions


Can be configured with different strategies:


Read
-
only
: fastest kind of cache can manage
read
-
only entity


Read
-
Write
: for entity that are also updated but
don’t support JTA


Nonstrict

read
-
write
: for object that are rarely
updated


Transactional
: for entity that use transaction in
JTA
enviroment
.
JBoss

implementation of this
cache support clustering

www.key2.
it


LOGO

Query cache


Holds query, its parameters and results to
avoid double database access for the
same interrogation


It’s used with the second level cache

www.key2.
it


LOGO

Statistics


Allow to obtain information on Hibernate
object’s status (session, session factory)
while application runs


Can be enabled or disabled at run
-
time with
specific
MBean

instance (Java Management
eXtension
)


Statistics type:

1)
General (sessions numbers, connection pool
size, etc.)

2)
Related to second level cache and entity

3)
Detailed on entity


www.key2.
it


LOGO

Q

& A

www.key2.
it


LOGO



KEy2.IT