File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Which way to cope with concurrent access?

 
savas karabuz
Greenhorn
Posts: 16
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Marshal
Posts: 33691
316
Eclipse IDE Java VI Editor
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Sol Mayer-Orn
Ranch Hand
Posts: 311
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic