2 Replies Latest reply on Mar 31, 2013 2:32 PM by markaddleman

    Proposal: New CommandListener callbacks for suspended executions

    markaddleman

      As mentioned in other posts, we have data sources that are very restricted in the number of concurrent connections that they can handle.  In order to better scale continuous queries across these data sources, what do you think about a couple of new callbacks:

      • CommandListener.commandSuspended()
      • CommandListener.commandResumed()

       

      Whenever the engine suspends a query (is there any reason other than an execution throwing DataNotAvailable?), all listeners would have a chance to release resources.  They could pick re-enlist the resources when the command is resumed.

       

      In our case, I imagine that many of our executions (both reusable and non-reusable) would become command listeners.  Other than threading issues, I don't see how this complicates the execution implementation much.  The only thing is that executions would have to unregister on their close/dispose in order to avoid a memory leak.  It might be convenient if the engine recognized an execution implementing CommandListener and automatically registering and deregistering it.

       

      What do you think?

        • 1. Re: Proposal: New CommandListener callbacks for suspended executions
          shawkins

          > all listeners would have a chance to release resources.  They could pick re-enlist the resources when the command is resumed.

           

          The only reason that Teiid should hold a connection with a given plan would be if there are still results to be read.  If there is a scenario where connections are being held beyond when the last result has been read and it's a non-lob results that is not marked as keep alive, then that's something that should be addressed via an issue.  Otherwise there's not really any action you could expect your listeners to take - for example releasing a database connection would likely close outstanding resultsets.  Perhaps what you are looking is an asynch translator that does not explicitly use a pooled resource.

           

          Steve

          • 2. Re: Proposal: New CommandListener callbacks for suspended executions
            markaddleman

            Oh, you're right.  I was thinking of a scenario involving two executions where the first throws DNA and the second would be suspended with an open connection.  That can't happen except for LOBs as you've mentioned.