SCJP 1.4, SCWCD 1.3, SCBCD 1.3
Your question is not clear,
you mean when ever i commit an sql query i have to put it in a try catch block or only one try catch block at the end of the querries?
i mean;
try{
conn.setAutoCommit(false); // start of JDBC transaction
delete from x table
conn.commit(); // end of JDBC transaction
}catch(Exception e){
conn.rollback();
}
.
.
.//another commit
try{
conn.setAutoCommit(false); // start of JDBC transaction
update x table
conn.commit(); // end of JDBC transaction
}catch(Exception e){
conn.rollback();
}
Batch?umm i think bacth works like this;
it adds all querries in an order in the statement and sends to database in one when executeBatch() method is invoked..
so i wonder how can i rollback if a problem occured in an sql query which is in the middle of the bacth?
can you advice me an ebook?or can i demand from you if you have a document.
SCJP 1.4, SCWCD 1.3, SCBCD 1.3
SCJP 1.4, SCWCD 1.3, SCBCD 1.3
[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
SCJP 1.4, SCWCD 1.3, SCBCD 1.3
[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
I'm still a little confused. I guess oracle database must be supporting optimistic locking right? I mean there are on locks actually, everybody is free to read and write except that the row timestamp/version is checked before doing an update. Now if trans-1 and trans-2 get to read the rows and trans-1 gets to update before trans-2. Say I have READ_COMMITED (oracle default as you mentioned) as isolation level. So trans-2 will get to see the updated row before it runs its update. The timestamp it read upfront wouldnt match the current timestamp and the update will not go through?.
SCJP 1.4, SCWCD 1.3, SCBCD 1.3
Originally posted by Roger Chung-Wee:
Indeed, the database will not commit if the timestamps differ. But that isn't the end of it. Remember, optimistic locking is not just provided by the DBMS: the developer has to code for this as well. So, you would expect the transaction to be immediately rolled back and, probably, the DB to be reread and a new transaction to be started.
I would also expect the developer to do some more work to ensure data consistency.
1. Enforce concurrency by using database triggers, otherwise you cannot guarantee database integrity.
2. Use a suitable integer for the concurrency key as the traditional date/time stamp only offers a one-second resolution for the lock.
3. Use an offset when writing back the key.
Did you see how Paul cut 87% off of his electric heat bill with 82 watts of micro heaters? |