[
https://issues.jboss.org/browse/TEIID-1801?page=com.atlassian.jira.plugin...
]
Steven Hawkins resolved TEIID-1801.
-----------------------------------
Resolution: Done
Added a RequestOptions object to the asynch methods on
TeiidStatement/TeiidPreparedStatement. It can be used to specify that a query should be
executed continuously. Thus continuous queries are currently limited to only embedded
jdbc using the Teiid extensions. If other modes are needed, non-embedded, odbc, etc.,
then we'll have to consider adding hints or other SQL based mechanisms.
Continuous queries will not be counted against the max active plans. Also, no built-in
mechanism is provided for specifying time windows. The general source hint mechanism can
be used for that purpose. If needed additional options can be added to the RequestOptions
object.
Note - I'm not sure if continuous is the best term or not.
At the translator level a new ReusableExecution interface was added so that custom
translators my return Executions that can be reused for the lifetime of the user query.
Close is still called as normal, but there is also a new ReusableExecution.dispose method
that is called when the user command finishes. As part of TEIID-1604 I'll also be
adding general callback mechanisms for notification of the end of user query and end of
session.
There is still more work to do on how to cache non-streaming results. The current
workaround is to use a session temp table or a matview to prevent unnecessary source
re-executions. Other possibilities include giving special meaning to the WITH clause
and/or some form of translator result set caching TEIID-1598. In general processing will
not be as efficient as it could be since we are not saving intermediate results, for
example if one side of a join is non-streaming and requires a Teiid sort, we will need to
perform the sort with each processing run. On the plus side though, the logic minimally
impacts the client and processing logic.
The rows returned through a continuous query cannot currently exceed 2^31-1. If this
limitation ever needs addressed, it would be far easier to modifying our result logic to
support longs rather than forcing the client to have more knowledge of continuous queries.
Async Event Processing: Reset and Re-run plan
----------------------------------------------
Key: TEIID-1801
URL:
https://issues.jboss.org/browse/TEIID-1801
Project: Teiid
Issue Type: Feature Request
Components: JDBC Driver, Query Engine
Reporter: Mark Addleman
Assignee: Steven Hawkins
Fix For: 8.0
In order to processing a stream of events aggregated within a specified time window, the
engine should provide some way of specifying the time period (analogous to a window),
reset and re-rerun the plan for every time period. There should also be an engine to
translator callback indicating that the plan has been reset as opposed to closed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira