Best Practice to Atomic Read and Write a Field In Database

Question

I am from Java Desktop Application background. May I know what is the best practice in J2EE, to atomic read and write a field in database. Currently, here is what I did
// In Servlet.
synchronized(private_static_final_object)
    int counter = read_counter_from_database();
    counter++;
    write_counter_back_to_database(counter);
}However, I suspect the above method will work all the time.
As my observation is that, if I have several web request at the same time, I am executing code within single instance of servlet, using different thread. The above method shall work, as different thread web request, are all referring to same "private_static_final_object"
However, my guess is "single instance of servlet" is not guarantee. As after some time span, the previous instance of servlet may destroy, with another new instance of servlet being created.
I also came across [http://code.google.com/appengine/docs/java/datastore/transactions.html|http://code.google.com/appengine/docs/java/datastore/transactions.html] in JDO. I am not sure whether they are going to solve the problem.
// In Servlet.
Transaction tx = pm.currentTransaction();
tx.begin();
    int counter = read_counter_from_database();  // Line 1
    counter++;                                                  // Line 2
    write_counter_back_to_database(counter);    // Line 3
tx.commit();Is the code guarantee only when Thread A finish execute Line 1 till Line 3 atomically, only Thread B can continue to execute Line 1 till Line 3 atomically?
As I do not wish the following situation happen.
(1) Thread A read counter from Database as 0
(2) Thread A increment counter to 1
(3) Thread B read counter from Database as 0
(4) Thread A write counter as 1 to database
(5) Thread B increment counter to 1
(6) Thread B write counter as 1 to database
What I wish is
(1) Thread A read counter from Database as 0
(2) Thread A increment counter to 1
(4) Thread A write counter as 1 to database
(3) Thread B read counter from Database as 1
(5) Thread B increment counter to 2
(6) Thread B write counter as 2 to database
Thanks you.
Edited by: yccheok on Oct 27, 2009 8:39 PM

Answer 1

This is my understanding of the issue (you should research it further on you own to get a better understanding):
I suggest you use local variables (ie, defined within a function), and keep away from static variables. Those local variables are thread safe. If you call functions within functions, its still thread safe. If you read or write to one record in a database using sql, its thread safe (you dont need a transaction). If you read/write to multiple tables and/or records, you probably need a transaction. Servlets are thread safe. You usually dont need the 'synchronized' word anywhere unless you have a function updating/reading a static variable and therefore want to ensure only one user is accessing the static varible at a time. Also do so if you are writing to some resource (such as a file, a variable in applicaton scope, session scope, or resource that everyone uses such as email server). You dont want more than one person at a time to write to it). Note the database is one of of those resources that is handled by transactions rather than the the synchronized keyword (the synchronized keyword is applied to your application only (not other applications that someone is running), whereas the transaction ensures all applications are locked out while you update those records in the database).
By the way, if you have a static variable, you should have one and only one function (synchronized) that updates it that everyone uses. If you have more than one synchronized function, that updates it, its probably not thread safe.
An example of a static variable you would use is a Datasource object (to obtain your database connections). You only need one connection pool in your application and you access it via the datasource variable.
If you're unsure your code is thread safe, you can create two seperate threads that call the same block of functions repeatedly to ensure it works as expected.