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.
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).
posted 8 years ago
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.?
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.).
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).
Never trust an airline that limits their passengers to one carry on iguana. Put this tiny ad in your shoe: