Spring Transaction Management 2

Spring Transaction Management

1)    ACID principle : Atomicity, Consistentency, isolation, durability 
2) You can handle transaction
    a)    in SQL
    b)    in JDBC
    c)    in ORM ( Hibernate, iBatis etc.. )
    d)    in EJB or Spring
    
3)    @Transactional annotation'i yalnizca servis metoduna konur. DAO metodlarina konmaz.
Cunku servis bircok DAO cagirabilir.

4) Propagation

@Transactional(propagation = Propagation.REQUIRED)

REQUIRED - uses the existing transaction. If it doesn't exist, creates a new one
REQUIRES_NEW - must start a new transaction. If there's an existing one, it should be suspended
SUPPORTS - if there is a transaction, runs in it. If there isn't, it just runs outside transaction context
NOT_SUPPORTED - must not run in a transaction. If there's an existing one, it should be suspended
MANDATORY - must run in a transaction. If there isn't one, it throws an exception
NEVER - must not run in a transaction. If there's an existing one, an exception will be thrown
NESTED - if there is a transaction, it runs withing the nested transaction of it. Otherwise it runs in its own

Default olani REQUIRED olan.
    
5)    Isolation

Concurrent Transaction Problems:

    a)    Lost Update
        Two transactions both update a row, second one rolls back, 
        both changes are lost
    b)    Dirty Read 
        Reading the changes without being committed. Rollback olursa patlar.
    c)    Unrepeatable read
        Ayni row'u iki kere select ederken, arada diger transaction commit
        ederse, ikincisinde farkli gorme.
    d)    Phantom Read - Unrepeatable a benziyor. Sadece ikinci transaction, insert yaparsa
        ve ilk transaction ozellikle bir satiri degil, kosulu select ediyorsa, ilk selecte
        gore daha fazla kayit gelebilir.

Isolation Levels:

DEFAULT - database isolation level, default
        Possible Problems:
        1)    unrepeatable read
        2)    phantom read
        3)  dirty read
        4)    Lost Update
READ_UNCOMMITTED - dirty read. No Lock.
        Possible Problems:
        1)    unrepeatable read
        2)    phantom read
        3)  dirty read
READ_COMMITTED - Write Lock
        Possible Problems:
        1)    Unrepeatable Read
        2)    Phantom Read
REPEATABLE_READ - Write Lock, Read Lock
        Possible Problems:
        1)    Phantom Read
SERIALIZABLE - No Problem, but performance is low - Write Lock, Read Lock, Range Lock



6)    Sadece Unchecked Exception lar rollback olur !
    Unchecked exception : RuntimeException

    a)Metod sorunsuz biterse commit
    b) catch edilen exception rethrow edilmezse, transaction commit.
    c) checked exception catch edilse de edilmese de ( rethrow olsa )
        transaction commit.
    d) unchecked exception catch edilmezse! o zaman rollback.
    
    Yukaridaki default olani. Eger ozellikle belirtmek istiyorsan:
    
    @Transactional(rollbackFor = IOException.class, noRollbackFor = RuntimeException.class)
    public void doSomething(...