• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

How to ensure db consistency - clustered application sharing common db

 
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I want to scale my java application by spreading it across a cluster. All nodes will share a common DB.

How can I ensure DB consistency? Is there a way to implement it without using any third party library?

I am trying to solve putIfAbsent kind of scenario. If one node is in middle of read-then-update a table row then all other nodes should stay away until first node is done.

What is the best and most simple way to implement this?

Cheers,
Ravi
 
Rancher
Posts: 989
9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you want to implement database row locking then you need to check your DBMSs manual. Locking on reads will probably result in very low performance. I would suggest going through http://docs.oracle.com/cd/B28359_01/server.111/b28318/consist.htm even though it's explaining these concepts for Oracle's implementation.
 
Bartender
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Aside from typical integrity contraints in the database, you could use roughly one of two strategies: pessimistic locking or optimistic locking. Which of the two is most applicable depends, for a large part, on the expected level of concurrency. The former involves locking the data at an appropriate level for access by a single session at a time, effectively blocking other sessions from read/writing the same data. The latter usually involves including a timestamp or version number in a record for the sole prupose of checking for modifications when a sessions attempts to update data - if the version or timestamp differs from when the data was read by the session a rollback is executed. If you use JPA, or an ORM framework by itself, you'll get support for different concurrency strategies out of the box. I wouldn't recommend implementing this yourself.
reply
    Bookmark Topic Watch Topic
  • New Topic