Re: problem multi-threading a stored procedure -- JAVA400-L

Thanks for the reply. The only way I know to use a seperate job for each user, is to create a seperate Connection for each user. Am I correct? Anyway, I am in the process of rewriting this so that a Connection will be created for each session. I will store the Connection object and the CallableStatement objects in the user's session. Now, I'm worried about sessions that timeout. I will provide a logout button that will invalidate the session and close statements and sessions. But, I know my users...they will ignore the logout button and just close the browser. So now I will have sessions that timeout. How will this effect the connection to the iSeries? I assume once the session is invalidated any objects stored in that session are marked for garbage collection. If a connection or statement get garbage collected will that "hang" the job on the AS400? Or, am I being too paranoid?

SRamanujan@xxxxxxxxxxxxxxxxxx wrote:

I think, in this scenario, the job i.e. qzdasoinit being the same, there
is no uniqueness to the different user.  That perhaps is the reason, the
2nd user gets 1st user's results.   I am still not sure how this should
work, since the 1st user responses will never be picked up or passed by
any job unless you introduce another control that tracks the user and
sends the result back to the cookies or user session or something.  Also
what if the same user signs in 2 different sessions?
When we came across the design issue, we used a different job for different user, however when the user is signed on, all requests from that user will pass through the same thread. This eliminated the mix-up. This worked out ok for us though.

But I believe there is a 3rd party plug-in that can handle same thread to be used for different users since it keeps track of the user signed in, somehow.
Thanks,
Sudha
-----Original Message----- From: TitanRebel [mailto:TitanRebel@xxxxxxxxxxx] Sent: Friday, March 07, 2003 1:24 PM To: java400-l@xxxxxxxxxxxx Subject: problem multi-threading a stored procedure

I am having a problem with a stored procedure. Hopefully, someone has experience with this. Here is my environment.
- Jakarta Tomcat 4.0.4 running on iSeries.
- Servlet calls a stored procedure to get list of results.
- Stored Procedure is written in RPG, running on same iSeries.
Everything works great when there are not simultanious requests to the same Stored Procedure. If two users request the results at approximately the same time, one of them doesn't get any results. From what I can tell, the second person to request the results get the results, and the first person gets none.

I have verified that the Servlet (as expected) is being executed in two seperate threads. The Connection and the CallableStatement are declared

as fields (class level variables). The ResultSet is a local variable that immediately gets turned into an ArrayList which is passed to a JSP page for display. So, I am using the same Connection for every user, and calling the "executeQuery()" method on the same CallableStatement.

Can anyone see what is wrong? My guess is that this connection is being

serviced by the same QZDASOINIT prestart job, therefore it is technically the same job that is calling the Stored Procedure each time,

and that is why it can't handle multi-threading. Does anyone know how to get around this? Should I create a seperate Connection object for each user? That seems ineffecient.
_______________________________________________
This is the Java Programming on and around the iSeries / AS400
(JAVA400-L) mailing list
To post a message email: JAVA400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.
_______________________________________________
This is the Java Programming on and around the iSeries / AS400 (JAVA400-L) 
mailing list
To post a message email: JAVA400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.