• 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
  • Tim Cooke
  • Devaka Cooray
  • Ron McLeod
  • Jeanne Boyarsky
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Piet Souris
  • Carey Brown
  • Tim Holloway
Bartenders:
  • Martijn Verburg
  • Frits Walraven
  • Himai Minh

Data concurency

 
Ranch Hand
Posts: 99
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
How do manage concurrency data access , deadlock etc from a j2ee appplication design prospective.Can you provide some recommendations for application design and DB design
 
author & internet detective
Posts: 41415
854
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Raj,
Basically, you use transactions to make sure the database stays consistent. This is a very general question, so I'm not sure how to give you a more specific answer. Can you expand on what you are looking for?
 
Ranch Hand
Posts: 1871
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Data concurrency issues are handled by setting the Isolation Level of the transaction, basically there are following four types of Isolation level we can set for any transaction.

Read Uncommitted
Read Uncommitted is No-Lock situation where one transaction can disturb other or it can create deadlock situation, it is generally not recommended, it is used only when you need some speed in your transaction.

Read Committed this is the default isolation level for most of the database servers and highly recommended. For read committed every statement in a transaction is locked until they are executed, when their execution is completed the lock is released, for insert, update or delete the transaction is locked until committed or rolled back. Read Committed prevents Dirty Reads situations when one transaction changes the data and the other transaction read the modified data and the first transaction the rollbacks so the second transaction only gets the wrong data.

Repeatable Read this isolation level is set for the situations where there is possibility of unrepeatable reads . When a transaction is set to Repeatable read then a transaction is locked until a transaction is committed or rolled back

Serializable This is the highest level of isolation generally not recommended it takes care of all the consistency problems (dirty reads, unrepeatable reads, phantoms) except lost updates. The Serializable isolation level allows a transaction to acquire read locks (if it only reads rows of data) or write locks (if it inserts, updates, or deletes rows of data) for the entire range of data that it affects. For example, if a transaction using the Serializable isolation level executes the SQL statement "SELECT * FROM ORDERS", the range is the entire ORDERS table. Therefore, the transaction acquires a read lock for the entire table and no new rows can be inserted into it until the transaction releases the lock.
[ March 07, 2006: Message edited by: Sameer Jamal ]
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic