• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

ORM and Transaction Isolation

 
Jean-Luc Thirion
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,

i am a beginner in ORM in general and i was reading a bit about the technics for scalability and performance.

I've juste read the article at: http://www.javaworld.com/javaworld/jw-07-2001/jw-0713-optimism.html?page=5
which is not difficult to understand.

But I have a stupid question on this page:
http://www.javaworld.com/javaworld/jw-07-2001/jw-0713-optimism.html?page=5

In the method:

the Application Server does (in the same transaction) something like:
1) a "select * from Customer_table where customer_id="+the_customer_id, an extracts the "version number"
2) if the version number has not changed, do "update Customer_table set .... where customer_id="+the_customer_id.

The problem that I see there is that if the transaction is done with the "transaction isolation level" < "repeatable read"(say, "read committed"), then the customer data which id is "the_customer_id" could be changed by another transaction between 1) and 2) ,and so the data extracted at 1) is stale.

Also, the ORM may generate a "SELECT FOR UPDATE" at 1) but that would be similar to an "PESSIMISTIC LOCKING" ?

Could somebody explain me if i am right ? Why the solution proposed in the article is safe (maintains the Consistency of the Database)?

Also could somebody tell me if the "transaction isolation level" could be defined precisely for each entity bean operation ?


Thanks in advance for your help,

JLT
[ January 31, 2008: Message edited by: Jean-Luc Thirion ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic