This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes JDBC and the fly likes need advice Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Databases » JDBC
Bookmark "need advice" Watch "need advice" New topic
Author

need advice

marko stone
Greenhorn

Joined: Oct 16, 2002
Posts: 23
hello i need advice
how right use rollback and commit ?
thanks
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:
try{
execute sql1
execute sql2
execute sql3
...
execute sqln
commit
}catch(Exception e){
rollback
}

HTH
marko stone
Greenhorn

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...
hth
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: http://aspose.com/file-tools
 
subject: need advice
 
Similar Threads
Another Satisfied Customer
Application security advice
Effect/Affect
carrer advice
What about startting Cordys BPM after J2EE exp.