wood burning stoves 2.0*
The moose likes JDBC and the fly likes Which way to cope with concurrent access? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Databases » JDBC
Bookmark "Which way to cope with concurrent access?" Watch "Which way to cope with concurrent access?" New topic
Author

Which way to cope with concurrent access?

savas karabuz
Greenhorn

Joined: Feb 24, 2004
Posts: 16
Hi all,

I want to know whether there is any difference between the following scenarios in a multi-threaded environment :

Say we have a function aMethod() that can be executed by more than one thread at a time in a class whose pseudo-code is something like :


Now, AFAIK insert and delete operations in aMethod() requires obtaining exclusive locks on the respective tables, so no one thread can ever insert into table A before its lock is released by the owning thread with a commit or rollback; effectively there is always only one thread executing inside aMethod() ant the other threads are waiting for the locks to be released. Am i right?

Is this situation the same with the following scenario, where access to aMethod() is synchronized? Here, still no two threads can be in aMethod() simultaneously, right?


Thanks in advance...
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30068
    
149

Savas,
The first example is preferred because you are letting the database handle the transaction. It also protects you from transactions occuring from other places besides your method. And the first example will perform faster under load because the database will be locked for the minimum amount of time.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Sol Mayer-Orn
Ranch Hand

Joined: Nov 13, 2002
Posts: 311
Hi,
I basically agree with the previous reply - the database should be allowed to manage its transactions.
I would only add that:

1) Additional point in favour of transactions -they allow greater flexibility in the future, since they can perform actions more interesting than simple locks (for instance, optimistic updates , or control over transaction isolation levels, or 2/3 phase commits in distributed environments).

2) Transactions allow rollbacks ! Java "synchronized" offers no contribution in that aspect.

3) However, in some pathological cases I found myself relying on both transactions and java synchronization. For instance, when managing both DB tables and some cache in memory.

Good luck
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Which way to cope with concurrent access?
 
Similar Threads
why my rollback doesn't work?
Threads, wait, notify and deadlocks.
Help: Basics of Thread
Date, time and timestamp
Multi-threading issues while handling JDBC transactions