Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Database concept

 
shai ban
Ranch Hand
Posts: 177
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 2985
12
Firefox Browser IntelliJ IDE Java Mac Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3752
62
Chrome Netbeans IDE Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 177
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3752
62
Chrome Netbeans IDE Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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).
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic