This week's book giveaway is in the OO, Patterns, UML and Refactoring forum.
We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line!
See this thread for details.
The moose likes JDBC and Relational Databases and the fly likes need advice Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

JavaRanch » Java Forums » Databases » JDBC and Relational Databases
Bookmark "need advice" Watch "need advice" New topic

need advice

marko stone

Joined: Oct 16, 2002
Posts: 23
hello i need advice
how right use rollback and commit ?
Juanjo Bazan
Ranch Hand

Joined: Feb 04, 2002
Posts: 231
You have to use Rollback and Commit in that cases where you have to do several SQL querys(for instance a set of inserts) and you want all to be done or if someone fails you want none to be done.
So a typical structure using commit and rollback is something like:
execute sql1
execute sql2
execute sql3
execute sqln
}catch(Exception e){

marko stone

Joined: Oct 16, 2002
Posts: 23
how i can lock table with it
( i mean that only one user can work with it)
Juanjo Bazan
Ranch Hand

Joined: Feb 04, 2002
Posts: 231
You can not use the 'commit' or 'rollback' commands to lock a table.
You can declare a method (for managing that table) as 'syncronized' to avoid more than one access at the same time.
But be sure of declaring as syncronized just the operations that really need to be syncronized, otherwise you may get performance problems...
Tina Coleman
Ranch Hand

Joined: Dec 12, 2001
Posts: 150
Note that setting the method as synchronized only affects folks coming in through the method. Folks hitting the table via other methods will not be locked out.
Take a look at setting the isolation level for your transaction (Connection.setTransactionLevel. Note that not all isolation levels are supported by all database drivers. Check DatabaseMetaData.supportsTransactionIsolationLevel). By setting the level on your transaction, you're getting the database itself involved, and thus other accesses will be bound by whatever locks you have in place. READ_UNCOMMITTED, READ-COMMITTED, REPEATABLE_READ, and SERIALIZABLE are the set of possibles. According to my Professional Java Data book, 'all rows visisted (whether modified or just read) by a REPEATABLE_READ are locked for the duration of the transaction with a shared lock. Shared locks allow concurrent transactions to read a resource, but no other transactions can modify the data while shared locks exist on that resource.'.
I agree. Here's the link:
subject: need advice
It's not a secret anymore!