[ https://issues.jboss.org/browse/TEIID-2584?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2584: --------------------------------------- Ah. Then we'll need to undo the change I just made to rename the property from create to start. I should be more particular. I mean memory resident, but backed by a database table. In particular if we were to use Hibernate to represent the status entries and rely on an infinispan second level cache. Ideally we'll minimize the check overhead as much as possible, but yes that query cost should be minimal. The alternative would be to expose the materialization table two ways. Once in a "regular" model and for management via a model that is associated with a more privileged connection. Although either way it seems like we have to by-pass normal authorization checks for the internal admin queries to work. The same concern exists for exposing the native query procedure. Are we saying that the materialization layer needs to by-pass the auth and even the translator checks associated with that? It seems like we may want to consider pulling more the business logic into Teiid so that we can avoid some of these issues (and probably the issue with starting an xa transaction). XA is involved because of the atomic blocks. -- 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