Write support when using read-committed transaction isolation

[David le Roux]

Hi all,

We have a use case where we would like to be able to commit transactions with the transaction isolation set to read-committed.

The operations we would like to perform during a transaction are very simple: limited to only reading the values of specific keys as well as writing the values of specific keys.

Is there any way to achieve this given that WiredTiger only supports write transactions if the transaction is set to snapshot isolation?

Thanks,

David

[Chenhao Qu]

Hi David,

You are right that the latest version of WiredTiger can only do write operations under snapshot isolation. May I ask why read-committed is needed in your use case? It is not clear to me based on your description that it needs to be read committed.

Thanks,

Chenhao

The information contained in this e-mail is confidential and is intended for the exclusive use of the addressee. Please notify the sender should you have received this e-mail in error and delete any copy in your possession.

--
You received this message because you are subscribed to the Google Groups "wiredtiger-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wiredtiger-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wiredtiger-users/0a1fd6a9-b609-4ef6-8e55-1057d09dcb30n%40googlegroups.com.

[David le Roux]

Hi Chenhao,

The intention is to be able to implement a simple version of serializable transaction isolation. Since our architecture is so simple, we can just block certain threads (transactions) (as well as having a basic scheduled deadlock detector). We need read-committed because we want to ensure we always read the latest committed versions of values, rather than a potentially "outdated" version.

Kind regards,

David

[Chenhao Qu]

Hi David,

WiredTiger read-committed isolation doesn’t guarantee that you can always read the latest committed version. The implementation of WiredTiger read-committed is to get a new snapshot when you call search or search_near. However, it always uses the same snapshot when you call next or prev. If a write is committed concurrently when you get the new snapshot in search, you may still not see it. For next and prev, because WiredTiger doesn’t refresh the snapshot, you are very likely to see outdated versions. If you never read with next or prev, read-committed may be useful to you but I still doubt it. I don’t know the details of your algorithm so I cannot give advice on what is the alternative. If I were you, I would consider using snapshot isolation with some retry logic. Hopefully this is useful to you.

Thanks,

Chenhao

To view this discussion on the web visit https://groups.google.com/d/msgid/wiredtiger-users/b2a21797-8c5b-46cb-a48c-8cabac7f7473n%40googlegroups.com.

[David le Roux]

Hi Chenhao,

Yes that is useful clarification for me thank you. We wouldn't use next or prev. We would always call search before we call get_value (similarly for set_value), but there would still then be a race condition since if another transaction committed just after we call search we wouldn't get the latest version. Although we should be able to prevent this race condition with our own blocking/locks.

But anyway since, as I understand it, writes are not an option with read-committed, we would have to consider rather using snapshot isolation. Your idea of some retry logic may be a viable solution.

Thanks again,

David