aspose file tools*
The moose likes JDBC and the fly likes Database concept Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Databases » JDBC
Bookmark "Database concept" Watch "Database concept" New topic
Author

Database concept

shai ban
Ranch Hand

Joined: Jan 05, 2010
Posts: 177
Hi all,
I am not able to understand the below concept...

"Transactions should be SERIALIZABLE" and "Transactions should not CONFLICT"

I am not able to link both statements! Please clear or refer some link etc.

Thanks.
Greg Charles
Sheriff

Joined: Oct 01, 2001
Posts: 2771
    
  10

We'd probably need to see the context of those statements. In particular, it doesn't make sense to say a transaction should be serializable unless you're talking about a transaction object of some kind.

Transactions not conflicting may mean they can't be access the same resources at the same time. For example, if I'm depositing $100 to my bank account and you're withdrawing $100 from yours, those are two transactions that probably don't conflict, and so can proceed at the same time. If we share a bank account though, the transactions may conflict, and so one of the transactions may be prevented from starting until the other is complete.
Martin Vajsar
Sheriff

Joined: Aug 22, 2010
Posts: 3447
    
  47

In this (though very vague) context, the serializable probably relates to transaction isolation level. Two transaction colud be said to be serializable if they can succeed concurently in serializable isolation level. In this case, the transactions are serializable if and only if they do not conflict. The concrete way to fulfill this requirement is at least partly database specific.

Secondly, when two concurrent transactions do conflict, one might have to wait to the completion of the other, as Greg described. This is not the only possible outcome, though. Other possible outcome is either a deadlock, or a related error that has to be remedied by retrying the failed transaction (eg. the "ORA-08177 can't serialize access for this transaction" error in Oracle).
shai ban
Ranch Hand

Joined: Jan 05, 2010
Posts: 177
So is my understanding is correct regarding SERIALIZABLE/CONCURRENT/CONFLICS

If the transactions are in SERIALIZABLE manner then you don't have CONFLICTS,

hence no CONCURRENCY problems like DIRTY READ, REPEATABLE READ etc.?
OR
SERIALIZABLE transactions have less throughput so CONCURRENT transactions are preferred. but they should be executed in such a manner than SERIALIZABILITY can be predicted (eg. ordering of transactions). Now because they are executing in concurrently, so CONFLICT may occur that should be handled by various ISOLATION levels (dirty read etc.).
Martin Vajsar
Sheriff

Joined: Aug 22, 2010
Posts: 3447
    
  47

I'd suggest to read up about transaction isolation levels in a JDBC tutorial or a similar resource. It is actually quite a difficult subject. If you're already reading one, it would help if you put up links to the passage you're discussing now, I've assumed (perhaps wrongly) some context and we may actually be speaking about different things.

SERIALIZABLE is a transaction isolation level, the others are REPEATABLE_READ, READ_COMMITTED and READ_UNCOMMITTED, sorted from the most to the least strict. Stricter isolation level provide better consistency of data as they are read from the database; if there were no other considerations, you'd want to use SERIALIZABLE only. However, this comes at a cost of concurrency - in some databases the data consistency is ensured by using locks, and quite understandably, more locks means lesser concurrency and throughput. So most of the time you'll use less strict isolation level, but you should always understand the ramifications and make sure that the isolation level you use either does not return inconsistent data (because of the design of your system), or that the inconsistency can be somehow lived with.

However, the isolation level is not the only factor that affects the level of concurrency of a transaction. A transaction that locks less database resources (eg. updates less rows) is generally more concurrent that a transaction that locks more, and transaction that takes less time (and therefore holds its locks briefly) is again generally more concurrent. Sometimes other factors (like ordering of commands inside the transaction) can affect its concurrency too, however, the concurrency can only be evaluated within the context of the system and database the application runs in (adding a new functionality - and transactions - into an application can cause concurrency problems with transactions that were non-problematic before).
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Database concept
 
Similar Threads
Downcasting
about logo
Hibernate 3.0 and EJB 3 specs
DOUBT from K&B
exclusive lock