Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

updating the database using Hibernate

 
ben oliver
Ranch Hand
Posts: 375
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Mahesh Gurav
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 375
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 375
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
so, the answer to my question is "Use transaction plus locking" ??
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Don't get me started about those stupid light bulbs.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic