Lock records

Question

Hey all,
I read most of the posts regarding this issue and I still can't find a solution to my problem, actually I don't really know what is my problem so here I am. This is the codes that I use to attempt to lock all the retrieved records
conn.setAutoCommit(false);
PreparedStatement pstmt = null;
ResultSet rs = null;
String query = "SELECT * FROM MYTABLE FOR UPDATE";
try {       
pstmt = conn.prepareStatement(query);
rs = pstmt.executeQuery();
} catch (Exception e) { }
then I test it by running 2 instances of this....however, it seems to me no matter what....both can modifies the table freely. Does anyone know what I am doing wrong? Thanks!

Answer 1

Also, WorkForFood would please give some a fragment
of codes that show how to declare a cursor FOR
UPDATE? PLEASE!I guess the point of my last post is that when you declare a cursor for update (which you do using SQL) it does NOT do what exactly what you want. You don't want to hint at locking the rows; you said you want to actually lock the rows. Here is the general syntax, check the DB2 reference manual for specifics:
"SELECT <columns-list> FROM <tablename> WHERE <where-expression> FOR UPDATE". OK, let's talk about what you are doing; which I think may be more the issue then how to do it. Why do you believe you should lock the rows? The DB2 authors have probably spent billions of dollars developing sophisticated lock managers that gracefully handle almost any situation that can arise when multiple users are accessing the same data concurrently. This begs the question, why are you special, and why do you think you can write it better then they did? Perhaps you already know the transactional flow within Java, but here is a bit of pseudo-code that may help out if you don�t.
CONNECT TO DATABASE
TURN AUTO-COMMIT OFF
START PROCESSING
DO WHILE ANOTHER TRANSACTION
   <TRANSACTION>
      SELECT FOR UPDATE (IF YOU WANT)
      PROCESS TO YOUR HEARTS CONTENT INCLUDING ADDITIONAL SELECT, INSERT, UPDATE, DELETE
      COMMIT ALL CHANGES
   </TRANSACTION>
END DO
END PROCESSING
DISCONNECT FROM DATABASE
Note: <TRANSACTION> is a logical step that occurs when you turn of auto-commit processing. There is nothing to code;, no syntax that actually starts the transaction. A transaction is what occurs between issuing of commits.
1) No one will see any of the changes you make to these rows until you issue the commit (that is the transactional processing). So if you are worried about people viewing partially changed content, it is a non-issue.
2) If someone were to issue an update against the same data you are updating, and you updated it first, their updates will wait and/or fail (and vice versa). There are standard Exception coding practices for handling that situation, but in a cooperative environment it comes up much less then you would think thanks to the DB2 gurus that wrote the lock manager.
3) Locking on large amounts of data in a batch or online program is a bad coding practice. If this is an online program, how long will you hold the lock while the user leaves a screen up and goes to lunch? Batch programs can deal with millions of rows. Locking on 100's or 1000's of rows that you �might� update can bring an application to a halt so again; avoid doing that through use of transactional processing.
I guess it's my contention that unless you have an extraordinary need, explicit locking of a table or rows within a table is not necessary. This en mass locking can and should be avoided through transactional processing which allows the DB2 lock manager to hide the complexity of concurrent usage.
If you are trying to fix a concurrency problem that is occurring in a production program, there may be another way to fix it. If this is a new program, focus on using transactions and I don�t think you will have to worry too much about the actual locking within the database.
This is just my two cents, and while there may not be anything new described here, I thought I would be remiss if I didn�t question a little on what you were doing rather then focus on how to do it. The issues and problems inherent in locking that you seem concerned about are not Java specific and you may want to consider asking similar questions in a DB2 forum.
WFF