[
https://jira.jboss.org/jira/browse/JBCACHE-1408?page=com.atlassian.jira.p...
]
Manik Surtani commented on JBCACHE-1408:
----------------------------------------
This is not as easy a solution as you think, since moving the code to handlePrepareCommand
means version info would not have been updated by the OptimisticValidationInterceptor and
stale version data would be written. I think the real solution (albeit not as performant
as you mentioned) is to ensure any ongoing txs are suspended beforehand and then resumed
after the DB write is completed.
Optimistic locking + JDBC cache loader + DataSources
----------------------------------------------------
Key: JBCACHE-1408
URL:
https://jira.jboss.org/jira/browse/JBCACHE-1408
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 2.2.0.GA, 3.0.0.ALPHA1
Reporter: Mircea Markus
Assignee: Manik Surtani
Fix For: 3.0.0.GA, 2.X
CacheStoreInterceptor.handleCommitCommand calls
CacheStoreInterceptor.storeInternalState.
In the optimistic scenario, this will try to add the version of the node (internal state)
to the previously stored nodes (nodes are being called in handlePrepareCommand).
The problem is that handleCommitCommand is called in an transaction having the status
Status.COMMITTED, and when trying to fetch a Connection,
org.jboss.resource.connectionmanager.TxConnectionManager checks for current tx status and
throws an exception if running tx is not active.
Solution: move the code which stores additional info in handlePrepareCommand. This should
also bring important performance gains, as for each node a new DB call is made in order to
add the version (see CacheStoreInterceptor.storeInternalState).
--
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