[
https://jira.jboss.org/jira/browse/ISPN-20?page=com.atlassian.jira.plugin...
]
Mircea Markus commented on ISPN-20:
-----------------------------------
I've just tried this approach but it fails due to the not-atomic nature of
CacheStore.store operation.
Store first checks that the entry is/isn't in the cache (1st interaction) and then
inserts/updates it.
Now following will fail
1. thread_1: calls store
2. thread_1: startLocalTx (conn.setAutocomit(false))
3. thread_1: read_entry //entry does not exist
4. thread_2: inserts_entry
5. thread_1: inserts same entry -> failure!
Now I've tried another approach in which instead of 3 I do an removeRow, just to
'force WL' on it, and then an inser directly, of course in the same local
transaction. This fails as well, bot with ReadCommited and RepetableRead. And that's a
bit strange, but guess there's not a total compliance for all vendors with isolation
level semantics. With this in mind it might be not such a bad idea to have our own locking
level and not rely on the database. Another approach would be to have a config element,
something like 'forceStoreLocking' - if true then use locking, othewise rely on
the database. This is a bit more complex, implementation wise. Also, we would have to test
at least with the popular databases and document which databases, with which isolation
levels etc can be relied on for locking...
check whether locking is needed within JDBC cache stores
--------------------------------------------------------
Key: ISPN-20
URL:
https://jira.jboss.org/jira/browse/ISPN-20
Project: Infinispan
Issue Type: Feature Request
Components: Loaders and Stores, Locking and Concurrency
Reporter: Mircea Markus
Assignee: Mircea Markus
Fix For: 4.0.0.BETA1, 4.0.0.GA
Not sure whether the 'outside' locking (MVCC) can't be used so that we
won't need locking code within cache stores
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira