Four Stars

tHash (outtput, input) and shared connection

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:

Main Job.JPGSharing a connection.JPG

Child Job <Test_SubJob>

Child_Job.JPGUsing shared connection.JPG

 

 

 

 

 

 

 

 

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

 

 

 

 

 

 

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

Connecting with context.JPG

 

 

 

 

 

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

 

Thanks in advance,

Dominique

 

 

5 REPLIES
Employee

Re: tHash (outtput, input) and shared connection

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.

Four Stars

Re: tHash (outtput, input) and shared connection

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

One Star

Re: tHash (outtput, input) and shared connection

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.

Ten Stars

Re: tHash (outtput, input) and shared connection

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.

Four Stars

Re: tHash (outtput, input) and shared connection

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...