Architecture of Popular

Object-Relational Mapping
Providers
Craig Russell
Mitesh Meswani
Larry White
TS-4856
2007 JavaOneSM Conference | Session TS-4856 |

Goal

How do architectures of Object-Relational

Mapping (ORM) frameworks affect
performance?

2007 JavaOneSM Conference | Session TS-4856 |

Agenda
Concepts of ORM
Major User-Visible Components
Major Internal Components
Performance Methodology
Key Findings/Recommendations
Call to Action

2007 JavaOneSM Conference | Session TS-4856 |

Concepts of ORM

Business Logic

Persistence aware
Uses persistence API

Domain
Objects

Persistence
Provider

Plain old Java objects

No persistence code

Mapping
Metadata

Persistence Provider

Persist, remove, query

Domain Objects

Business
Logic

Implements persistence API

Mapping Metadata

Database

Domain to database
2007 JavaOneSM Conference | Session TS-4856 |

Agenda
Concepts of ORM
Major User-Visible Components
Major Internal Components
Performance Methodology
Key Findings/Recommendations
Call to Action

2007 JavaOneSM Conference | Session TS-4856 |

Persistent Class

The domain object persisted in database

Instances might be persistent (or not)

2007 JavaOneSM Conference | Session TS-4856 |

Persistence Unit

Singleton pattern for VM (JNDI)

DataSource definition
Metadata for mapping to database

Entity classes
Rows, columns, primary/foreign keys

2007 JavaOneSM Conference | Session TS-4856 |

Persistence Context

Represents a collection of entities managed by

a persistence provider on behalf of a single user
For each persistent identity, there is a unique
entity instance in a given persistence context
For exampleEntities managed by

Java Persistence API (JPA) EntityManager or

Java Data Objects (JDO) PersistenceManager

2007 JavaOneSM Conference | Session TS-4856 |

Query API

Provides query using domain model artifacts

Entity classes
Persistent fields/properties
Relationships

Persistence provider translates to SQL

Or underlying native query language (QL)

One domain query translates to one native QL

2007 JavaOneSM Conference | Session TS-4856 |

Second Level Cache

Managed in persistence unit

Contains entities used at least once by any
persistence context in a persistence unit
For each persistent identity, contains the
unique entity instance last updated in a
persistence context
Cached entities can become stale

2007 JavaOneSM Conference | Session TS-4856 |

10

Connection Pooling

Access to database requires a connection

Connections are expensive to acquire
Connection is transactional (or not)
Connections can be serially reused

2007 JavaOneSM Conference | Session TS-4856 |

11

Field vs. Property Persistence

Persistent fields

Fields behave according to Java platform access

modifiers

Private, protected

Persistence provider uses reflection or byte code

Enhancement to access fields

Persistent properties

JavaBeans architecture style get/set methods

Both user contract and persistence provider

No validation

Violates separation of concerns

2007 JavaOneSM Conference | Session TS-4856 |

12

Byte-code Enhancement
a.k.a. weaving, transforming

Class byte codes modified for efficiency

Requires changes to deployment

Direct access to fields without reflection

Automatic change tracking
Lazy field loading
Dynamic instrumentation via Java technology agent
[Java Platform, Standard Edition (Java SE platform)]
Dynamic instrumentation via transformer
[Java Platform, Enterprise Edition (Java EE platform)]

Static enhancement provides more options

2007 JavaOneSM Conference | Session TS-4856 |

13

Agenda
Concepts of ORM
Major User-Visible Components
Major Internal Components
Performance Methodology
Key Findings/Recommendations
Call to Action

2007 JavaOneSM Conference | Session TS-4856 |

14

Major Internal Components

Persistence unit

DataSource (Connection Factory)

Persistent class metadata

Second-level cache

Persistence context

Entity maps/lists

Statement cache, query cache

Transactional entities: map<key, entity>

Modified entities: list<entity>

SQL generator/resultSet handler

2007 JavaOneSM Conference | Session TS-4856 |

15

Internal Architecture
Persistence Context

Persistence Unit

Cache
Manager
Modified
List

ID
Map

2nd Level
Cache

Transactional
Cache

Mapping
Metadata

Data Access

SQL Generation
ResultSet Processing
Statement Caching
Connection Pooling

2007 JavaOneSM Conference | Session TS-4856 |

16

Connection/
Statement
Pool

Lazy Loading/Change Detection

OpenJPA uses byte code enhancement

JPOX uses byte code enhancement
TopLink essentials uses byte code enhancement

Reflection for change detection

Hibernate uses reflection for change detection

Doesn't load lazily with field persistence

2007 JavaOneSM Conference | Session TS-4856 |

17

Agenda
Concepts of ORM
Major User-Visible Components
Major Internal Components
Performance Methodology
Key Findings/Recommendations
Call to Action

2007 JavaOneSM Conference | Session TS-4856 |

18

Performance Methodology

Can we really do that?

Performance is difficult to measure (technically)

Choose a workload
Choose a configuration
Choose products to measure
Measure, verify, repeat (until exhaustion)

Performance is difficult to measure (legally)

Restrictions, covenants, licenses

Open Source Changes Everything
Well almost

2007 JavaOneSM Conference | Session TS-4856 |

19

Performance Methodology

How do we do that?

TheorizePredict relative performance

Qualitative understanding of architecture

Caching, data access, change detection

Conduct experiments
Analyze and correlate with measurements
Modify workload and repeat

2007 JavaOneSM Conference | Session TS-4856 |

20

Performance Methodology
Why should we NOT do that?

All workloads are different

Workloads are composites of atomic use cases

Typically 5 to 15 use cases

Find, query, retrieve object graph, update, delete

Vary mix and correlation

eBay is different from amazon

2007 JavaOneSM Conference | Session TS-4856 |

21

Performance Methodology
Why should we NOT do that?

Micro benchmarks are trivial

Workloads are composites

Each individual operation is trivial but in aggregate
represents real work
Quantity has a quality all its own

2007 JavaOneSM Conference | Session TS-4856 |

22

Performance Methodology
Why should we NOT do that?

Why should you trust a vendor?

ORM frameworks are open source

We dont need to trust vendors

The community can engage this problem
Users can modify to suit their requirements

2007 JavaOneSM Conference | Session TS-4856 |

23

Measuring Performance

Workload driver

Operations implementation

Operations (create, read, update, query, navigate)

Mix (e.g. 10%, 60%, 5%, 20%, 5%)
Timing requirements (90% percentile within 2 seconds)
Use persistence adapter to do work
Translate operation to adapter API

Scale number of parallel threads

Measure operations per second

Increase parallelism until metric decreases
2007 JavaOneSM Conference | Session TS-4856 |

24

DIY Open Source Project

Allows users to run their own workloads

Sample workloads and configurations provided
URL http://diy.dev.java.net
Suggestions and contributions encouraged

2007 JavaOneSM Conference | Session TS-4856 |

25

Connection Pooling Performance

Operations per second

Hibernate Connection Pooling

140
135
130
125
120
115
110
105
100
95
90
85
80
75
70
65

No Pool
Pool

40

50

60

70

80

90

100 110 120 130

Users
2007 JavaOneSM Conference | Session TS-4856 |

26

TopLink Essentials Field vs. Property

Ops per second

Field vs. Property

375
350
325
300
275
250

Field
Property

225
200
175
150
125
100
50

100

150

200

250

300

350

Users
2007 JavaOneSM Conference | Session TS-4856 |

27

Use Second Level Cache

Operations per second

OpenJPA Second Level Cache

220
200
180
160
140
120

No Cache
Cache

100
80
60
40
20
0

25

50

75

100

125

Users
2007 JavaOneSM Conference | Session TS-4856 |

28

Use Byte-code Enhancement

Operations per second

TopLink Essentials Enhancement

375
350
325
300
275
Enhanced
Not Enhanced

250
225
200
175
150
50

100

150

200

250

300

350

Users
2007 JavaOneSM Conference | Session TS-4856 |

29

Key Findings

And recommendations

Use second-level cache

Use connection pooling
Use byte-code enhancement
Use field persistence

2007 JavaOneSM Conference | Session TS-4856 |

30

Call to Action

Performance tuning is required

For all but the most trivial applications

Its much too hard to tune persistence

Performance monitoring should be automatic

Should have to turn it off if you dont want it

Should enable access strategy tuning

Part of every database access

Take a look at DIY Project

2007 JavaOneSM Conference | Session TS-4856 |

31

Q&A
Craig Russell
Mitesh Meswani
Larry White
http://diy.dev.java.net

2007 JavaOneSM Conference | Session TS-4856 |

32

Architecture of Popular
Object-Relational Mapping
Providers
Craig Russell
Mitesh Meswani
Larry White
TS-4856
2007 JavaOneSM Conference | Session TS-4856 |