topic tHash (outtput, input) and shared connection in Talend Studio

tHash (outtput, input) and shared connection

Anonymous — Fri, 07 Jul 2017 15:13:23 GMT

Hi,

I'm new in Talend and i'm designing a job running child jobs (with tRunJob).

I'm sharing the connection of the main job with the child jobs.

It works fine exept for one child job where i'm storing records in a tHashOutput and then later reading those records with a tHashInput.

The tHashOutput and the tHashInput are in two different subjobs connected with "OnSubjobOk".

By running the application i get following message:

Exception in component tHashInput_1
java.lang.RuntimeException: The hash is not initialized : The hash must exist before you read from it

If i transmit the whole context to the child-job and connect the database with the context variable (no more shared connection) it runs without error and i don't understand why!

here the screenshots of the application with the error:

Main job:

Child Job <Test_SubJob>

In the second version, the one without error i transmit the whole context to the child-Job:

and in the child Job i connect with the context variables:

It would be great if someone could explain me why it doesn't work with the shared connection.

Thanks in advance,

Dominique

Re: tHash (outtput, input) and shared connection

Anonymous — Fri, 07 Jul 2017 22:04:50 GMT

Are you sure you are specifying the "Use or Register a shared DB Connection" in both connections? I saw in one of your screenshot on the GKT connection where you do not have that option ticked.

Re: tHash (outtput, input) and shared connection

Anonymous — Sat, 08 Jul 2017 01:40:31 GMT

Hi iburtally,

Yes i'm sure, the connection you see without the shared connection is the one using just the context variables. It runs then without error but I have to connect two times to the database; one time in the main job and one time in the child job. And it should be possible to connect just in the main job. And for all other child job it works, just not for this child job with the tHashOutput and tHashInput.

Thank you for helping

Re: tHash (outtput, input) and shared connection

Anonymous — Mon, 10 Jul 2017 14:07:31 GMT

Hi,

I don't want to sidetrack the main issue of this posting but whilst I do not have precisely the same issue (yet!), I do have a related issue and this is a perfect context to ask the question.

I am basically trying to do exactly the same as what is being done in this posting, i.e. create a HashOut in a parent job and use a connected HashIn in a child job. I need to do this because I am assembling data from many sources into a single table and to do all that in a single job will result in something of a monster job design. After scouring the postings and other sources the closest thing I can find to a definitive answer is that this cannot be done.

This posting suggests this scenario will work if the connection is set up correctly which now runs counter to my understanding.

I would be very grateful if someone could advise on this. Should I persist or do I need to take a back step and look at a different design approach to achieve this.

Re: tHash (outtput, input) and shared connection

cterenzi — Mon, 10 Jul 2017 15:38:30 GMT

I am guessing the original poster's problem is that the database connection in the child job is not initializing, and so is putting no rows into the Hash. I haven't used shared DB connections before, but from what I can see in the documentation, the components are configured correctly. Maybe someone with more experience using shared connection could weigh in.

As for the followup question, you are correct in assuming that you cannot populate a Hash in a parent job and read from it in a child job. The original poster was attempting to share a database connection between jobs, not a Hash. The Hash is just the component that threw an error.

Re: tHash (outtput, input) and shared connection

Anonymous — Wed, 12 Jul 2017 08:38:22 GMT

Hi cterenzi,

thank you for trying to help and spending time on my problem.

I don't have yet the explanation of this issue but it isn't too critical because by direct connecting, and not sharing the connection, to the database, the child job can do what it has to do...