[infinispan-issues] [JBoss JIRA] Commented: (ISPN-20) check whether locking is needed within JDBC cache stores

[Mircea Markus (JIRA)]

    [ https://jira.jboss.org/jira/browse/ISPN-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12469456#action_12469456 ] 

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