[ https://issues.jboss.org/browse/ISPN-1340?page=com.atlassian.jira.plugin.... ] Marcel König updated ISPN-1340: ------------------------------- Attachment: ReadCommittedLockTest.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1340?page=com.atlassian.jira.plugin.... ] Manik Surtani updated ISPN-1340: -------------------------------- Fix Version/s: 5.1.0.ALPHA1 5.1.0.FINAL Priority: Critical (was: Major) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1340?page=com.atlassian.jira.plugin.... ] Manik Surtani resolved ISPN-1340. --------------------------------- Fix Version/s: (was: 5.1.0.FINAL) (was: 5.1.0.ALPHA1) Resolution: Rejected -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1340?page=com.atlassian.jira.plugin.... ] Manik Surtani updated ISPN-1340: -------------------------------- Fix Version/s: 5.1.0.ALPHA1 5.1.0.FINAL -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1340?page=com.atlassian.jira.plugin.... ] Manik Surtani updated ISPN-1340: -------------------------------- Summary: ReadCommitted - commited Cache.remove is not visible to other transactions (was: ReadCommittedLock - commited Cache.remove is not visible to other transactions) Complexity: High -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1340?page=com.atlassian.jira.plugin.... ] Manik Surtani edited comment on ISPN-1340 at 9/12/11 12:06 PM: --------------------------------------------------------------- Agreed, but this still should be acceptable since isolation levels are a _minimum_ level of isolation that should be expected. E.g., if you configure *READ_COMMITTED* but end up with something closer to *REPEATABLE_READ* that is fine. What would be a real problem is if you end up with _weaker_ isolation. So in this case, you're saying when you configure *READ_COMMITTED*, you end up with seeing committed data most of the time, except when the data is concurrently removed, in which case you see *REPEATABLE_READ* semantics. This should be fine, since you should never write code to _expect_ a weaker isolation level. Isolation levels are only configured to be weaker as a performance tradeoff. In this particular case, forcing Infinispan to give you strict *READ_COMMITTED* for deleted entries will result in a large performance penalty for what is weaker isolation. So the tradeoff isn't really worth it. was (Author: manik): Agreed, but this still should be acceptable since isolation levels are a _minimum_ level of isolation that should be expected. E.g., if you configure *READ_COMMITTED* but end up with something closer to *REPEATABLE_READ* that is fine. What would be a real problem is if you end up with _weaker_isolation. So in this case, you're saying when you configure *READ_COMMITTED*, you end up with seeing committed data most of the time, except when the data is concurrently removed, in which case you see *REPEATABLE_READ* semantics. This should be fine, since you should never write code to _expect_ a weaker isolation level. Isolation levels are only configured to be weaker as a performance tradeoff. In this particular case, forcing Infinispan to give you strict *READ_COMMITTED* for deleted entries will result in a large performance penalty for what is weaker isolation. So the tradeoff isn't really worth it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1340?page=com.atlassian.jira.plugin.... ] Manik Surtani edited comment on ISPN-1340 at 9/12/11 12:06 PM: --------------------------------------------------------------- Agreed, but this still should be acceptable since isolation levels are a _minimum_ level of isolation that your app can deal with. E.g., if you configure *READ_COMMITTED* but end up with something closer to *REPEATABLE_READ* that is fine. What would be a real problem is if you end up with _weaker_ isolation. So in this case, you're saying when you configure *READ_COMMITTED*, you end up with seeing committed data most of the time, except when the data is concurrently removed, in which case you see *REPEATABLE_READ* semantics. This should be fine, since you should never write code to _expect_ a weaker isolation level. Isolation levels are only configured to be weaker as a performance tradeoff. In this particular case, forcing Infinispan to give you strict *READ_COMMITTED* for deleted entries will result in a large performance penalty for what is weaker isolation. So the tradeoff isn't really worth it. was (Author: manik): Agreed, but this still should be acceptable since isolation levels are a _minimum_ level of isolation that should be expected. E.g., if you configure *READ_COMMITTED* but end up with something closer to *REPEATABLE_READ* that is fine. What would be a real problem is if you end up with _weaker_ isolation. So in this case, you're saying when you configure *READ_COMMITTED*, you end up with seeing committed data most of the time, except when the data is concurrently removed, in which case you see *REPEATABLE_READ* semantics. This should be fine, since you should never write code to _expect_ a weaker isolation level. Isolation levels are only configured to be weaker as a performance tradeoff. In this particular case, forcing Infinispan to give you strict *READ_COMMITTED* for deleted entries will result in a large performance penalty for what is weaker isolation. So the tradeoff isn't really worth it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira