I'm separating the connections into different jobs in some of my experiments... but that was intended to be used for the experimental settings (i.e., not for master now)...
I think the interesting question here is whether we want to allow one Hyracks job to carry multiple transactions. I personally think that should be allowed as the transaction and job are two separate concepts, but I couldn't find such use cases other than the feeds. Does anyone have a good example on this? Another question is, if we do allow multiple transactions in a single Hyracks job, how do we enable commit runtime to obtain the correct TXN id without having that embedded as part of the job specification. Best, Xikui On Thu, Nov 16, 2017 at 1:01 PM, abdullah alamoudi <[email protected]> wrote: > I am curious as to how feed will work without this? > > ~Abdullah. > > On Nov 16, 2017, at 12:43 PM, Steven Jacobs <[email protected]> wrote: > > > > Hi all, > > We currently have MultiTransactionJobletEventListenerFactory, which > allows > > for one Hyracks job to run multiple Asterix transactions together. > > > > This class is only used by feeds, and feeds are in process of changing to > > no longer need this feature. As part of the work in pre-deploying job > > specifications to be used by multiple hyracks jobs, I've been working on > > removing the transaction id from the job specifications, as we use a new > > transaction for each invocation of a deployed job. > > > > There is currently no clear way to remove the transaction id from the job > > spec and keep the option for MultiTransactionJobletEventListenerFactory. > > > > The question for the group is, do we see a need to maintain this class > that > > will no longer be used by any current code? Or, an other words, is there > a > > strong possibility that in the future we will want multiple transactions > to > > share a single Hyracks job, meaning that it is worth figuring out how to > > maintain this class? > > > > Steven > >
