[ https://issues.jboss.org/browse/TEIID-2584?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2584: --------------------------------------- They could be but we don't consider them as currently supported. I'm confused on what you mean by requests (user request?). I'm saying that within the scope of a load procedure if you use a transaction specifically around the test for loading: {code} BEGIN ... declare boolean shouldLoad; BEGIN ATOMIC update status set (isLoading = true) WHERE ... and isLoading = false; shouldLoad = (ROWCOUNT = 1); END if (shouldLoad) ... END {code} Then regardless of the isolation level if shouldLoad is true, then you would proceed. This of course glosses over any of the complexity with failed loads or initially populating a status entry. As you are getting though if this is being run in the scope of a higher level transaction, then there will be an issue. No I think that is what you have to do. Adding the consideration of implicit loading strategies is cumbersome. Not exactly - it provides a more centralized coordination mechanism and more easily allows for hard time based refreshing (refresh all at midnight, etc.). However the real trick with freshness is based upon change events and incremental updates. -- 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