6720 Jazoon09 HiberateOffliner v1 5€¦ · Presentation layer Processing layer/ services Data access layer ... – Uses Hibernate to access the database (the approach can be adapted

Hibernate OfflinerConvenient Disconnected Mode for your Rich Java Application

David Bernhard, Master Student (former ELCA intern)

ETH Zurich

Philipp Oser, Lead Architect

ELCA Zurich

6720

2AGENDA

> Introduction

– How to use the Hibernate Offliner?

– Informal introduction: Offline and Synchronize

> The gory details

– The Offliner Cycle

– Object Graphs

– Conflicts

– More Features

– Limitations

> Qualitative performance

> Demo

3ELCA portrait

ELCA is one of the leading independent Swiss companies in the IT development and system

integration field.

We develop, integrate, operate and maintain IT solutions using custom developed applications,

as well as industry standards.

Founded in 1968

Employees ~ 500 employees

Offices Lausanne (head-quarters), Zurich, Geneva, Bern, London,

Madrid, Paris, Ho Chi Minh City (Vietnam)

Turnover CHF 71 millions, uninterrupted positive results for 20 years

Quality Standards ISO 9001 since 1993

CMMI Level 3 since 2007

Awards

4

Introduction

5

Example Scenario

Scenario:

> You use an application with a rich Java client that works with an application server.

> You want to be able to use it offline, e.g. on your laptop.

What is needed for your application to work offline:

> You need to store a subset of the data locally to work with it.

> You need to synchronize the data with the server when you are back at the office.

What is desirable:

> Your existing application should not require major changes.

Presentation layer

Processing layer/ services

Data access layer

process boundary

6

Preconditions for the Hibernate Offliner

> Requires a Java application (both on client and server)

– Uses Hibernate to access the database (the approach can be adapted to

other technology)

– Uses the DAO pattern to access the database (our approach is loosely

coupled to the DAO interface, but we had to assume some interface)

> Some restrictions on what Hibernate features you can use (more later)

> No special adaptations required for your data model (you just need to add 2 new

database tables on the client for bookkeeping)

7

3 steps to make an application offline-capable (1)

original 1) add local DB & processing 2) add offline control & conflict resolution

copy existing layers, adapt a bit can be mostly generic

Presentation layer

Processing layer/

services

Data access layer

Presentation layer


Data access layer

Processing layer/

services

Data access layer

process boundary

Presentation layer

Processing layer/

services

Data access layer

Processing layer/

services

Data access layer

Offline control

& Conflicts

Offline control

& Conflicts

8

3 steps to make an application offline-capable (2)

2) add offline control & conflict resolution 3) add server-side offlining functionality

is part of the offliner (fully generic)

Presentation layer


Data access layer

Processing layer/

services

Data access layer

Offline control& Conflicts

Offline control

& Conflicts

Presentation layer

Processing layer/

services

Data access layer

Processing layer/

services

Data access layer


Offline control

& Conflicts

Server-side Offlining

support

9

How does your application work?

Trivial (offlining does not change this):

> Work online

> Work offline

Interesting cases:

> A) Go from online mode to offline mode

> B) Go from offline mode to online mode

> Refer to next 2 slides

Presentation layer


Data access layer

Processing layer/

services

Data access layer


Offline control

& Conflicts

Server-side

Offlining

support

10

A) Go from online mode to offline mode

1. The user indicates that he wants to

take some data with him (i.e. that he

wants to offline some data,

e.g. all clients from the Zurich area).

2. The application loads this data from

the remote database.

3. The application hands this data to

the offliner for local storage.

4. The offliner does some local

bookkeeping.

Presentation layer


Data access layer

Processing layer/

services

Data access layer

Offline control

& Conflicts

Offline control

& Conflicts

Server-side

Offlining

support

1.

2.

3.

4.

11

B) Go from offline mode to online mode

1. The user indicates that he wants to synchronize the local data data with the server.

2. The offliner finds all locally changed data (2a.) and tries to update it on the server (2b.).– May cause optimistic locking

conflicts.

3. The offliner deletes all data on the server that was marked for deletion on the client.– May cause optimistic locking

conflicts.

4. The offliner finds all changed data on the server that exists in an older version on the client and updates it.

5. Conflict handling in GUI.

Presentation layer


Data access layer

Processing layer/

services

Data access layer

Offline control

& Conflicts

Offline control

& Conflicts

Server-side

Offlining

support

1.

2a.3. & 4.

2b.

5.

12

The gory details

ORM – The Offliner Cycle – Object Graphs – Conflicts – More Features – Limitations

13ORM : Normal Operation


14ORM – Normal operation / CRUD

Application ORM

CRUD ORM allows for operations like

create, read, update, delete ...

Application sends domain objects to the

ORM and gets them back changed.

Object’s class and (primary) key, version

are only identifying characteristics for ORM.

Object

key

version

data

DB

15ORM – Create

Application ORM

Object

key = 0

version = 0

data

create

Object

key = 123version = 0

data

create:

• Object with key zero.

• Returned with key from

ORM/Database.

16ORM – Update

Application ORM

Object

key = 123

version = 0

data

update

Object

key = 123

version = 1

data

update:

• Object with key not zero.

• Entry with given key

updated in database.

• Version increased (or

conflict reported).

17The Offliner Cycle

Offline

Synchronize

Work offline


18Offliner – Offlining

ApplicationLocal DB Remote DB

ObjectObject

Offlining: Read object from remote database and save it to local one.

Offline

Synchronize

Work offline

19Offliner – Working offline


Object

Disconnect from remote database and work with local one.

Aim: Identical interface to application.

Offline

Synchronize

Work offline

20Offliner – Synchronizing


Object

Object

Synchronizing: Copy object back to remote database.

Offline

Synchronize

Work offline

21Offlining

Local DB Remote DB

Object

key = 123

version = 10

data

Fetch object from remote DB.

Offline

Synchronize

Work offline

22Offlining

Local DB Remote DB

Object

key = 123

version = 10

data

Problem: We cannot save an

object into a database it did not

come from.

Its primary key does not have

the same meaning there.

Offline

Synchronize

Work offline

23Offlining

Local DB Remote DB


Mapping Entry

remote key = 123

remote version = 10

local key = 0

local version = 0

Object

key = 0

version = 0

data

Store key, version in mapping

entry and set to zero.

Offline

Synchronize

Work offline

24Offlining

Local DB Remote DB


Mapping Entry

remote key = 123

remote version = 10

local key = 0

local version = 0



Object

key = -10

version = 0

data

Save to local database and

recieve new key.

Offline

Synchronize

Work offline

25Offlining

Local DB Remote DB




Object

key = -10

version = 0

data

Save to local database and

recieve new key.

Store new key in mapping

entry. Save it locally as well.

Mapping Entry

remote key = 123

remote version = 10

local key = -10

local version = 0Offline

Synchronize

Work offline

26Synchronizing

Local DB Remote DB

Object

key = -10

version = 0

data

Mapping Entry

remote key = 123

remote version = 10

local key = -10

local version = 0

Object

key = 123

version = 10

data

Offline

Synchronize

Work offline

27It works!

Remote DB

Object

key = 123

version = 10

data

Object

key = 123

version = 10

data

From point of view of remote

database:

Object is fetched and updated later.

Only data has changed, key and

version are identical.

This is exactly the same situation as

working without an offliner.

offline

synchronizeOffline

Synchronize

Work offline

read

update

28Object Graphs


29Object graphs

Person

PK: integer

name: string

parent: FK (Person)

address: FK (Address)

Address

PK: integer

city: string

Person

Person Person

Person Address

Address

Objects have relations, expressed in foreign/primary key mappings.

Offlining/Synchronizing an object applies to the whole object graph

it references.

30The graph walker

An object can only be created once all its children have been created.

Item a = new Item();

db.create(a);

// A now has PK set correctly

Item b = new Item();

b.setReference(a); // Java reference

db.create(b);

// B now has PK set. FK in database.

A

key = 123

data

B

key = 456

data

Creating object graphs in a database (without offliner).

31The graph walker

Rule: An object can only be saved/updated once all its children

have been processed.

Aim: offline(B)

B has FK to A.

create(B) in local database requires

• A must exist there already.

• A’s key field must be set correctly.

• B’s key must be 0.

A

key = 123

data

B

key = 456

data

32The graph walker

A

key = 123

data

B

key = 456

data

A

key = -1

data

B

key = 456

data

offline(A)

A has no children.

OK to set key to 0

and save.

All children of B have been

processed.

OK to set key to 0 and save.

A

key = -1

data

B

key = -2

data

offline(B)

33The graph walker

Rule: An object can only be saved/updated once all its children have been processed.

1.

2. 3.

5. 4.

6.

The graph walker runs during each

offline/synchronize operation.

(Whenever we modify keys/versions).

It ensures every change is carried out

correctly on the whole object graph.

Each object is processed individually, in

post-order (children before parent), using

visitors.

34Conflicts


35Conflicts

Application Remote DB Application

read

read

update

update – conflict!

A conflict is a situation where an object has been modified by another user

between two offliner operations (offline/synchronize).

36Conflicts - ORM

DB

Object

key = 123

version = 2

Object

key = 123

version = 2

Object

key = 123

version = 1

new data

new data

data

updateSame version – OK

Version is incremented

during update.

Other version –

Conflict!

37Conflict Management

Offliner returns list of conflicted objects after each offline/synchronize operation.

Objects that depend on (have references to) conflicted objects cannot be

processed – these are reported too.

“Force” operations exist to resolve conflicts (example: overwrite remote version

with local one).

38Conflict Management - Forcing

Remote DBApplication

Person

key = 123

version = 1

my data

Person

key = 123

version = 2

their data

Person

key = 123

version = 2

my data

update

39More Features


40Chunking

Application Offliner

Local DB Remote DB

Server

Chunking controls how objects are exchanged between offliner and server.

An object can only be sent together with its complete object graph

(serialization).

Strategies can be adapted to layout (breadth, depth, size) of object graphs.

41Deletion

Use case: User deletes object while working offline and runs synchronization.

Expectation: Object will be deleted on server/remote database too.

Order of deletion is important.

Solution: Proxy all local DAOs and record deletes in mapping entry. They are

processed during synchronization.

1. 2.

3.

42The Offliner Interface

interface Offliner implements DaoRegistry {

// DaoRegistry

GenericDao getFor(Class cls);

// Turn application online or offline.

// Determines which database DaoRegistry uses.

void setOnline(boolean online);

boolean isOnline();

// Offline and synchronize data.

Conflict[] offline(Object... objects);

Conflict[] synchronize();

// Conflict resolution methods.

Conflict[] forceLocal(Object obj);

Conflict[] forceRemote(Object obj);

// ... (listing is not complete)

}

43Limitations


44Limitations

• Offliner cannot guess “incoming” links.

Parent

Child Child

Remote DBLocal DB

Parent

Parent.countChildren() = 0 Parent.countChildren() = 2

offline(Parent)

45Limitations

• Trivially: Offliner does not work with thin clients – application logic must be on

client. Only Java with Hibernate supported.

• Cascading saves – can lose a lot of efficiency.

• For now: it works directly with our DaoRegistry and DAOs (deliberate choice)

• Some restrictions on types of keys and versions.

• Keys in local and remote databases must come from disjoint sets.

• Some transactional compromise (we don’t replay the transactions to reduce # of conflicts).

• Lazy associations do not work.

• It is a prototype - not used yet in a real-world project.

46

Performance and Demo

47

Qualitative performance

For each object in local db (normal case): compare with

version on the server & synchronize with each other (3

or 4 db operations, well cacheable & batchable)

Handle objects marked for deletion

Synchronize data

For each object (normal case): 1 store operation in local

db

Bookkeeping: naïve implementation uses 2 db accesses

/ object (could be cached)

Offline data (in

addition to selecting them in the real db)

Same as without the Offliner (+2 db operations per

object delete for bookkeeping)

Working offline

Same as without the OfflinerWorking online

Cost of the operationOperation

48

Demo

> Simple data model using Parent – Child

> GUI is generic (allows generic editing of POJOs

via DAOs)

> Sample interaction:

– Start online, edit data

– Move some data in local db (“offline data”)

– Continue to edit data online

– Go offline

– Edit data offline

– Go online

– Synchronize dataHandle conflicts

– Edit data online

parent

*

Offline

Synchronize

Work offline

ParentChild

firstValue: String

secondValue: String

49

Conclusion

The Hibernate Offliner provides you with non-intrusive offlining for your rich Java

applications

Check it out under

> http://EL4J.sourceforge.net

> Source code in SVN repository of sourceforge

> Documentation in chapter 18 of http://EL4J.sourceforge.net/docs/pdf/ReferenceDoc.pdf

David Bernhard, Master Student www.ethz.ch

ETH Zurich

Philipp Oser, Lead Architect www.elca.ch

ELCA AG, Zurich Firstname.Lastname A T elca.ch

Documents

6720 Jazoon09 HiberateOffliner v1 5€¦ · Presentation layer Processing layer/ services Data access layer ... – Uses Hibernate to access the database (the approach can be adapted