File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Object Relational Mapping and the fly likes updating the database using Hibernate Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Databases » Object Relational Mapping
Bookmark "updating the database using Hibernate" Watch "updating the database using Hibernate" New topic
Author

updating the database using Hibernate

ben oliver
Ranch Hand

Joined: Mar 28, 2006
Posts: 375
I am new to Hibernate. I have a basic question --- What if I need to frequently update my database or add/delete rows by using Hibernate ? I want to make sure that when one client is updating the row, the others will be waiting, i.e. there should be a good locking mechanism. Does Hibernate "automatically' take care of it ? Do I have to use Hibernate transaction feature for this ?

Thanks
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17250
    
    6

Yes, you will want to use their transactions, which will hook into an EJB Transaction if you already have one. In Hibernate it is as simple as. 1. Get Session, 2. Get Transaction, 3. Update/insert/delete 4. commit. 5. Close session

Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Mahesh Gurav
Greenhorn

Joined: Oct 18, 2004
Posts: 21
Mark,
I think ben is asking Question about hibernate and u have given answer with reference to EJB transaction,i hope hibernate transaction are also work on the same rules.
If ben is asking about concurrency issue & according to u if hibernate is handling this issue by transaction only,then what is Pessimistic locking & optimistic locking.Can you elaborate the point.
refrence for locking mechanism:Hibernate in Action.Chapter 5.1.7
Thanks
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
Hibernate automatically employs optimistic locking provided you provide a version_id/timestamp in the mapping. That means that only the first update (with the same version_id) will succeed while all subsequent update attempts will fail. You can however manually specify a pessimistic lock through Session.load() (with LockMode) Session.lock(), or Query.setLockMode() � in a DB like Oracle that will result in the use of "SELECT ... FOR UPDATE". The creators of Hibernate feel that pessimistic locking does not scale well.
See Chapter 10. Transactions And Concurrency
ben oliver
Ranch Hand

Joined: Mar 28, 2006
Posts: 375
Bear with me, I am sort of confused here ---

What I need is to make sure that at any given time only one client can update the database, after it is done, the next one can update it... It seems there are two issues going on here -- transaction and locking. Now,

1. do I have to put the 'update" operation inside a transaction ?
2. from Mark's response, he didn't mention using any lock. But the other two fellows mentioned about locking. I guess I should use one of the two locking mechanism. SO, does that mean I have to use "locking" plus "transaction" ?
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
Originally posted by ben oliver:
What I need is to make sure that at any given time only one client can update the database, after it is done, the next one can update it...

This is usually known as concurrency control (part of which is concerned with locking). Transactions were initially introduced to make multiple interdependent DML actions atomic (ACID � atomicity, consistency, isolation, durability). A transaction may be applied to a SELECT to ensure that the read is consistent (i.e. you don�t end up retrieving some partially updated rows and or columns because an UPDATE is in progress) and a transaction may be applied to a (single) update to ensure isolation, i.e. one update only proceeds after the other completes. Concurrency control makes sure that an update will only happen against the data that was originally read � the update will be impossible (pessimistic concurrency) or aborted (optimistic concurrency) if another update has occurred since the last read.

Have look at Developer's Corner - Optimistic And Pessimistic Concurrency � it skims the issues of concurrency control.
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17250
    
    6

Originally posted by Mahesh Gurav:
Mark,
I think ben is asking Question about hibernate and u have given answer with reference to EJB transaction,i hope hibernate transaction are also work on the same rules.
If ben is asking about concurrency issue & according to u if hibernate is handling this issue by transaction only,then what is Pessimistic locking & optimistic locking.Can you elaborate the point.
refrence for locking mechanism:Hibernate in Action.Chapter 5.1.7
Thanks


My answer was given in Hibernate. You do the exact same 5 steps whether you are using EJB or not. You can remove the transaction part, if you don't want to use transactions, but that is scary in my mind.

Mark
ben oliver
Ranch Hand

Joined: Mar 28, 2006
Posts: 375
so, the answer to my question is "Use transaction plus locking" ??
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
More accurately "Use transactions AND concurrency control", which still leaves you to choose your style of concurrency control (pessimistic vs. optimistic). The database may choose independently to lock data currently under the influence of a transaction - so the term "locking" can be a bit overloaded when it comes to transactions and concurrency control.

Get Hibernate In Action (Hibernate In Action (ThoutReader + PDF ebook)), it discusses the issues in detail.
Radhika Bhagavathula
Greenhorn

Joined: Feb 11, 2011
Posts: 2
Hi Mark, Peer

I have been using a similar scenario for my application where I am using transactions + concurrency control. I tried using optimistic and pessimistic locking but it does not seem to work
I am using Spring and Hibernate 3.2.5.
My application scenario is :
1) user can select multiple number of files from the UI
2) for each file a NEW transaction is run consisting of SELECT and UPDATE

However, if I select 2 files for example, for processing, instead of:

SELECT
UPDATE
SELECT
UPDATE

the order of execution shows

SELECT
SELECT
UPDATE
UPDATE

the second transaction starts even before the first transaction finishes and reads the not yet updated values (dirty read).
I tried pessimistic locking with Query.setLockMode which does not seem to work with DB2 which is the database I am using. I also tried to set the hibernate.transaction.isolation values and also on the Spring side with isolation attribute for @Transactional annotation.

Can somebody please help me where am I going wrong/what additional needs to be done so that the second transaction starts only after the first finishes. Appreciate your help.
Radhika Bhagavathula
Greenhorn

Joined: Feb 11, 2011
Posts: 2
Just and update from my side. Because none of the locking methods worked, I used synchronized for the Spring method which already was annotated @Transactional and it worked.
Now the order of execution is :

SELECT
UPDATE
SELECT
UPDATE
AND SO ON...

is this the correct approach? is there an alternative to using synchronized as this might be overhead for performance? Appreciate your suggestions.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: updating the database using Hibernate