[infinispan-issues] [JBoss JIRA] (ISPN-686) JdbcStringBasedCacheStore loads previous data from store before an insert
[
https://issues.jboss.org/browse/ISPN-686?page=com.atlassian.jira.plugin.s...
]
Sanne Grinovero commented on ISPN-686:
--------------------------------------
I wonder if the race condition is really possible with a write-through configuration: in
theory the writing node owns a lock on the written entry.
I guess it's more tricky for async cacheloader: it's unlikely because of the
de-duplication of writes on the same key, but still possible.
Yes for Oracle you need a stored procedure to implement it properly, but what's wrong
with suggesting & documenting that? Especially as many other databases do have a
solution, like UPSERT or MERGE.
I don't like the Transactions approach as it could interfere with other transactions
integration; this doesn't look like the proper layer to manage transactions.
JdbcStringBasedCacheStore loads previous data from store before an
insert
-------------------------------------------------------------------------
Key: ISPN-686
URL: https://issues.jboss.org/browse/ISPN-686
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 4.0.0.Final, 4.1.0.Final
Reporter: Sanne Grinovero
Assignee: Thomas Fromm
Fix For: 5.2.0.Alpha3, 5.2.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, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira