aspose file tools*
The moose likes JDBC and the fly likes Data concurency Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Databases » JDBC
Bookmark "Data concurency" Watch "Data concurency" New topic
Author

Data concurency

raj joe
Ranch Hand

Joined: Mar 17, 2005
Posts: 99
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
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30780
    
157

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?


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Sameer Jamal
Ranch Hand

Joined: Feb 16, 2001
Posts: 1870
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 ]
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Data concurency