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?
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.
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.