[infinispan-issues] [JBoss JIRA] Commented: (ISPN-686) JdbcStringBasedCacheStore loads previous data from store before an insert

[Sanne Grinovero (JIRA)]

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

Sanne Grinovero commented on ISPN-686:
--------------------------------------

+1 for the new tablemanipulation method.
I won't assume update is more common, in the case of the LuceneDirectory it's extremely unlikely, it's picking a new key for each write; (that's why I'm attempting to avoid the return value at all costs, totally pointless).

Assuming we go for the UPDATE + INSERT strategy, is there a lock on the key held to protect from a race condition?

> JdbcStringBasedCacheStore loads previous data from store before an insert
> -------------------------------------------------------------------------
>
>                 Key: ISPN-686
>                 URL: https://jira.jboss.org/browse/ISPN-686
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Loaders and Stores
>    Affects Versions: 4.0.0.Final, 4.1.0.Final, 4.2.0.ALPHA2
>            Reporter: Sanne Grinovero
>            Assignee: Trustin Lee
>             Fix For: 4.2.0.BETA1, 4.2.0.Final, 5.0.0.Final
>
>
> The JdbcStringBasedCacheStore implementation loads the previous data on an insert to find out if it should generate an UPDATE or INSERT statement, while it would perform much better to just verify if the primary key exists.
> On top of this, some databases provide ways to avoid the need to check at all, like MySQL's " INSERT ... ON DUPLICATE KEY UPDATE"
> [http://dev.mysql.com/doc/refman/5.0/en/insert-on-duplicate.html]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira