Lifecycle of resuable executions got changed after patch from https://issues.jboss.org/browse/TEIID-2322

[gamvi01]

Hi

I observed there was a change in lifecycle of reusable execution after applying the patch for https://issues.jboss.org/browse/TEIID-2322.

Earlier for a query like below where data_window is a call to storeprocedure in a translator . This storeprocedure execution is an instance of ReusableExecution.

SELECT chorus_results.name, chorus_results.CHORUS_C_notesForObject, 'demodata.nullObj' AS "__objecttype__" FROM (EXEC data_window('SELECT /*+sh:''data_window'' */ CHORUS_B.*, ''demodata.nullObj'' AS "__objecttype__" FROM (SELECT CHORUS_B.* FROM (SELECT * FROM demodata.nullObj) AS CHORUS_B, (EXEC chorus_time.timetable(30000)) AS chorus_refresh_expression) AS CHORUS_B WHERE CHORUS_B.name = ? LIMIT 100', ?)) AS chorus_data_window, ARRAYTABLE(chorus_data_window.tuple COLUMNS name string, val string, "__objecttype__" string) AS chorus_results LIMIT 6

Execution used to be :

1) call to data_window translator createProcedureExecution

2) which gets routed to corresponding instanceof ProcedureExecution -> execute method

3) In execute we trigger a async request and on call back we insert data to h2 temp table . Until the callback is received for data available we throw data no polling exception.

4) when the callback to async request got fulfilled we select the data from h2 temp table.

New execution :

1) call to data_window translator createProcedureExecution

2) which gets routed to corresponding instanceof ProcedureExecution -> execute method

3) In execute we trigger a async request and on call back we insert data to h2 temp table . Until the callback is received for data available we throw data no polling exception.

4) a new call is being triggered to data_window translator

5) if we have the data available we select tehe data from h2 tables

why is it we are triggering a new request rather than just calling execute as before?

[shawkins]

> 4) a new call is being triggered to data_window translator

Is your translator forkable (the default) such that it can be called asynchronously?  What you may be seeing is that the Execution is not be closed (which can happen in a different thread) before the next Execution is being requested.  You can confirm this by verifing that Execution.close is being called and that for subsequent reuse after the first you are getting an existing execution.  This is a stricter lifecycle than what was enforced prior to the patch - which simply assumed the Execution was ready for reuse after reset and did not strictly enforce that the prior close would be called before reset.

If this is the behavior you are seeing, you could have your translator return isForkable false - which would make all interactions with the Executions happen synchronously in the processing thread.  However if it's still desirable to use a separate thread for execution/results, then a more specific property, such as synchClose could be added.

Steve

[shawkins]

This discussion should be merged with https://community.jboss.org/thread/221321?tstart=0