Hi everyone,

I'm fairly new to Hibernate, so I'm sorry for what may be a newbie question.

My question is architecture/design related. I'm hoping you can provide some insights before I start designing/coding.

The A in Ajax stands for Asynchronous - meaning I can do multiple interactions on a given page without waiting for the previous request to finish up. This is great from a UI perspective but how does this sit with Hibernate, especially when updating the same domain object?

Here's an example - I have a a class representing a Task. A Task has a description and a status (eg completed, not started etc). Let's say my UI allows the user to change the description and status via independent Ajax requests. The user does not have to wait till one request to finish before submitting the next request. Would Hibernate be able to cope with the independent update requests and not override the data?

For instance, let's say Task 1 has description="Hello" and status="not started". The user changes the description="World" and clicks save. This creates an Ajax request to save. While waiting for a response,
the user then changes the status="completed". Would it be possible to end up having a persisted state of description="Hello" and status="completed"?

I know Hibernate has Level 1 cache and a switch to update a column only if changed. I'm not sure how things would work in practise with timing and transaction.

The sequence of event would be:

1) User submits description.
2) System retrieves entire Task instance from database.
3) System copies updated description to Task instance.
4) System updates Task details.
5) User submits status.
6) System retrieves entire Task instance from database.
7) System copies updated status to Task instance.
8) System updates Task details.

What if Steps 5 and 6 happen before Step 4 to result in:

1) User submits description.
2) System retrieves entire Task instance from database.
3) System copies updated description to Task instance.
4) User submits status.
5) System retrieves entire Task instance from database.
6) System updates Task details.
7) System copies updated status to Task instance.
8) System updates Task details.

The Task details in Step 8 does not have the status correctly populated.

Any thoughts? Can this happen with Hibernate or does synchronization and internal state management prevent this somehow?

thank you.

There is no magical bullet for the type of scenarios that you describe. You may want to add the case of multiple users.

One of the mechanisms that Hibernate offer is the opportunistic locking. You should read the details about Transactions and Concurrency here http://www.hibernate.org/hib_docs/v3/re ... tions.html

For the case of a single user, you may want to keep a local model inside the browser with the state of (some) objects. Everytime you send an object you can send all of the object properties, this way you will reduce concurrency problems. Since the transit times may be different for different requests you can do something like the following:
1. UI updates the model and sets flag
2. you have an updater thread that sends modifications to the backend
3. you can have some strategy that serializes the request and/or uses a quiet time (fire every 5 seconds, if model dirty and last mod time more than 5 seconds ago then sends backend request)

I hope this helps :)

Marius

Hi Marius,

Thanks, that's a good solution. If I understand you correctly, the solutions basically have to be client side and either come in the form of

1) serialised requests (to guarantee order) or
2) a polling mechanism to batch requests.

The serialized request approach can probably be implemented as a "please wait" dialog which while visible, prevents further submits. In Dojo for example, via dojo.widget.Dialog.

http://download.dojotoolkit.org/release ... alog3.html

The batching has the added advantage of reducing the load on the server too (eg instead of five update requests to the same instance, just one).

Are there any other approaches out there? What's everyone else doing?

I realised that the previous suggestion with batching wasn't going to work. The reason is because validation typically happens on the server side (also there might be a host of business logic checks). This meant that batching can create a false impression that an update has successfully occurred, which isn't good.

In the end, I applied a pessimistic strategy in a test case using LockMode.UPGRADE. This worked! I simulated two threads accessing the same record via session.get(class, id, lockMode), the second definitely blocks until the first transaction completes.

This is the most ideal situation because the UI can still be asynchronous and responsive. The only thing to remember with pessimistic locking is to make sure deadlocks are handled and/or avoided.

Thanks for sharing. Now your challenge will be to scale the system :) Some load testing will show you how things stand in terms of requests/second with and without locking.

Marius