wood burning stoves 2.0
The moose likes JDBC and Relational Databases 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
JavaRanch » Java Forums » Databases » JDBC and Relational Databases
Bookmark "Which way to cope with concurrent access?" Watch "Which way to cope with concurrent access?" New topic

Which way to cope with concurrent access?

savas karabuz

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
author & internet detective

Joined: May 26, 2003
Posts: 32626

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.

[OCA 8 book] [Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Sol Mayer-Orn
Ranch Hand

Joined: Nov 13, 2002
Posts: 311
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?
It's not a secret anymore!