-
Notifications
You must be signed in to change notification settings - Fork 226
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
scalikejdbc.DBConnection#readOnly does not honor isolationLevel #1143
Comments
I also suspect using |
Thanks for sharing this. The recommended way for performing queries with a particular isolation level is to use a NamedDB(dbName.name).isolationLevel(IsolationLevel.Serializable).localTx { implicit s =>
// select query here
} |
It is beneficial to use read only transactions when other transactions are
serializable so the db can know they can’t cause a serialization failure.
…On Thu, Dec 17, 2020 at 6:01 PM Kazuhiro Sera ***@***.***> wrote:
Thanks for sharing this. The recommended way for performing queries with a
particular isolation level is to use a localTx block. It works even when
you do not run updates in it.
NamedDB(dbName.name).isolationLevel(IsolationLevel.Serializable).localTx { implicit s =>
// select query here
}
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1143 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AALTNNKRCWQCTS3NN44LYU3SVKEULANCNFSM4U4U2JZQ>
.
|
Thanks for the prompt reply. While I am open to supporting read-only transactions, I am not going to work on it in the short term. Actually, we got a request #542 four years ago but it's not done yet. Please go with your workaround for now. |
Sure, I am not blocked by this. More importantly though is that the way
isolation level is handled makes stateful changes to database connections
and when pools are used there are situations where the prior use of a
connection affects the current.
In my particular case I use serializable transactions to write and read
committed transactions to read, all using the same connection pool. Since
read committed is the default I was not setting the isolation level.
Eventually all connections were set to serializable leading to unexpected
serialization failures.
On the whole, scalikejdbc has been a pleasure to use. Thanks.
…On Thu, Dec 17, 2020 at 8:00 PM Kazuhiro Sera ***@***.***> wrote:
Thanks for the prompt reply. While I am open to supporting read-only
transactions, I am not going to work on it in the short term. Actually, we
got a request #542 <#542>
four years ago but it's not done yet. Please go with your workaround for
now.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1143 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AALTNNKUBXYXHDVT666V5ILSVKSRVANCNFSM4U4U2JZQ>
.
|
NamedDB(dbName.name).isolationLevel(IsolationLevel.Serializable).readOnly
does not propagate the isolation level down to the database connection. When using a connection pool,readOnly
reuses the isolation level set by the previous use of the connection.Our workaround sets the isolation directly on the connection:
The text was updated successfully, but these errors were encountered: