Connection pooling and unique job number - IBM AS400

This is a discussion on Connection pooling and unique job number - IBM AS400 ; Hi everyone, I'm interfacing a legacy application to a web based front end. I have a stored function on the iseries that creates data in a work file. The problem is the client user interface needs to read this work ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Connection pooling and unique job number

  1. Connection pooling and unique job number

    Hi everyone,

    I'm interfacing a legacy application to a web based front end. I have a
    stored function on the iseries that creates data in a work file.

    The problem is the client user interface needs to read this work file based
    on job number, but the client uses connection pooling so the job number is
    the same for all client jobs. This means that 2 users could over write each
    others data.

    The same problem would exist if using qtemp for the work file because
    connection pooling shares qtemp as there is only one "job number" active.

    Is there anything I can use (perhaps in the program data structure) to
    identify a unique client connection?

    Thanks.
    Kent



  2. Re: Connection pooling and unique job number

    On Jul 14, 12:48*pm, "Kent Knapp" wrote:
    > Hi everyone,
    >
    > I'm interfacing a legacy application to a web based front end. *I have a
    > stored function on the iseries that creates data in a work file.
    >
    > The problem is the client user interface needs to read this work file based
    > on job number, but the client uses connection pooling so the job number is
    > the same for all client jobs. *This means that 2 users could over writeeach
    > others data.
    >
    > The same problem would exist if using qtemp for the work file because
    > connection pooling shares qtemp as there is only one "job number" active.


    >
    > Is there anything I can use (perhaps in the program data structure) to
    > identify a unique client connection?


    well the RPG program in the server job which is being reused ( because
    of the connection pool ) could have activation group *NEW. The RPG
    program would then know it is being called for the first time and then
    either clear the file in QTEMP or do some sort of processing to assign
    a unique key to its set of records in the common work file.

    I might not understand how your apps is working, but it has to be that
    the connection pooling is happening on the client side. The server
    side, where the RPG program is running will not be sharing its QTEMP
    with any other job.

    -Steve


  3. Re: Connection pooling and unique job number

    > I might not understand how your apps is working, but it has to be that
    > the connection pooling is happening on the client side. The server
    > side, where the RPG program is running will not be sharing its QTEMP
    > with any other job.
    >


    The problem isn't that the stored procedure will share QTEMP with
    another job, but that serial calls to the procedure could re-use the
    same pre-start job (probably QSQSRVR or QZDASOINIT) and thus re-use
    the same QTEMP.

    The OP will have to come up with an alternative key to associate calls
    with results (in similar-ish circumstances I've had success using data
    from the QWTRTVTA API, combined with a timestamp, to get a GUID), or
    abandon connection pooling for these calls.

  4. Re: Connection pooling and unique job number

    Yes walker is correct, issue is using the same pre-start job.

    Ok I will give this more thought, thank you for your help.

    Kent

    "walker.l2" wrote in message
    news:87384a01-9743-4c18-82bf-71b32115e44c@r66g2000hsg.googlegroups.com...
    >> I might not understand how your apps is working, but it has to be that
    >> the connection pooling is happening on the client side. The server
    >> side, where the RPG program is running will not be sharing its QTEMP
    >> with any other job.
    >>

    >
    > The problem isn't that the stored procedure will share QTEMP with
    > another job, but that serial calls to the procedure could re-use the
    > same pre-start job (probably QSQSRVR or QZDASOINIT) and thus re-use
    > the same QTEMP.
    >
    > The OP will have to come up with an alternative key to associate calls
    > with results (in similar-ish circumstances I've had success using data
    > from the QWTRTVTA API, combined with a timestamp, to get a GUID), or
    > abandon connection pooling for these calls.




  5. Re: Connection pooling and unique job number

    If the amount if data produced by the procedure is not very large,
    using (keyed) DTAQs could be a useful solution.

+ Reply to Thread