[infinispan-issues] [JBoss JIRA] Commented: (ISPN-686) JdbcStringBasedCacheStore loads previous data from store before an insert
[
https://jira.jboss.org/browse/ISPN-686?page=com.atlassian.jira.plugin.sys...
]
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