Optimistic Concurrency Nedir

Giriş

Optimistic Concurrency aynı zamanda Row Versioning olarak ta bilinir. 

Amacı Nedir?

Açıklaması şöyle. Uzun süren bir işlemde, READ COMMITED yetersizdir. REPETABLE READ ise bir başkasının yazma işlemini engeller. Ancak biz hem başkasını engellememek hem de değişiklik varsa Lost Update problemine sebep olmamak istiyoruz.

The objective of optimistic concurrency is to minimize the time that a given resource is unavailable for use by other transactions. This is especially important with long-running transactions, which under a pessimistic scheme would lock up a resource for unacceptably long periods of time.

Veri tabanı Tarafı Çözümü

Bazı veri tabanları Optimistic Concurrency için özel isolation seviyesi sağlar. Örneğin SQL Server, READ COMMITTED SNAPSHOT seviyesi sağlar. Bazıları da sağlamaz. SQL Server için açıklama şöyle. 

As you already know, the READ COMMITTED isolation level has two forms. The first form applies to the pessimistic concurrency model, while the second form applies to the optimistic concurrency model. This section discusses the former. The second form, READ COMMITTED SNAPSHOT, is discussed in the following section, “Row Versioning.”

İstemci Tarafı Çözümü

Eğer veri tabanı bu yeteneği sağlamıyorsa, Row Versioning istemci tarafından yapılır. Açıklaması şöyle

Optimistic locking is application-side check whether the timestamp/version of a record has changed between fetching and attempting to update it.

Burada Hibernate için bir örnek var. Bu örnekte READ COMMITED seviyesi kullanılıyor, dolayısıyla veriyi güncellemek isteyen başka birisi engellenmez. Ancak hibernate versiyon bilgisi de kullandığı için Lost Update problemi de engellenir.

Aslında bu çözüm veri tabanı kullanılmayan durumlar için de kullanılabilir. Wikipedia' da veri tabanı kullanmayan bir örnek var.

Optimistic Concurrency Ne Zaman Kullanılmalı

Açıklaması şöyle. Eğer başarısızlığın bize maliyeti fazla ise Optimistic Concurrency tercih edilmemelidir. Bu gibi durumlarda, en iyisi satırı/tabloyu işlem sonuna kadar kilitlemektir.

Whether to use optimistic concurrency depends on the type of transaction.

Transactions with a high penalty for failure might be better managed with a pessimistic scheme. A high-penalty transaction is one for which recovery is risky or resource-intensive.

For low-penalty transactions, it is often worth the risk of failure to gain efficiency through the use of an optimistic scheme.

In general, optimistic concurrency is more efficient when update collisions are expected to be infrequent; pessimistic concurrency is more efficient when update collisions are expected to occur often.