• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Devaka Cooray
  • Tim Cooke
Sheriffs:
  • Rob Spoor
  • Liutauras Vilda
  • paul wheaton
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Mikalai Zaikin
  • Carey Brown
  • Piet Souris
Bartenders:
  • Stephan van Hulst

Which way to cope with concurrent access?

 
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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...
 
author & internet detective
Posts: 41995
911
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Morning came much too soon and it brought along a friend named Margarita Hangover, and a tiny ad.
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
reply
    Bookmark Topic Watch Topic
  • New Topic