Adding a member to a file is a fairly tedious task for the database engine. I'd think you'd do better to do write the entire temp table back to your webserver and store it as xml in the webserver's temp directory. JT400 JDBC is actually set up to do this for you without chewing up memory. When you get a result set back from a query, the records aren't actually transmitted until you read them (though there's some buffering for performance). So the webservice should create and open the xml file, open the JDBC connection and do the query. When the result set comes back, work through the result set record at a time reading the record and writing it to the xml file. At the end of the result set, close the xml file and then reopen it to start writing the http response.
If you really must hold the temp results on the i, store them in xml files in the IFS. Use the username or session id as the file name.
I've done the multi-member thing as you suggest, but it's been a long time ago. As I recall, we had trouble keeping it tidy. Removing a member (RMVM) doesn't necessarily free the space on the i. What happens if the webservice stops asking before reaching the last chunk? How do you know to remove that member? (You'll have this problem with IFS files, too.)
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Michael Naughton
Sent: Wednesday, November 21, 2012 1:43 PM
To: Midrange Systems Technical Discussion
Subject: Design Question - Multi Member Files
I'm curious what people's thoughts are on the following situation. I've got a web application that makes multiple requests to our iSeries through a non-i web server, receiving back information each time until there is nothing more to send. The only persistent piece is the browser; the web server application fires up with each request, contacts the iSeries, gets a reply, and sends it back to the browser. (It's the potential size of some of the possible replies that is driving this -- the server app has some limits that might be exceeded if everything came back all at once.)
The iSeries application builds a work file on the first pass and then reads through it, sending the information back to the web. The design issue is how to maintain persistence on the data in the work file in a situation where multiple people may be doing this at once. My solution right now is to make the work file multi member, so each user uses a member named for their user profile and the program does an OVRDBF to that member on the way in.
It seems like a nice, neat way to use a handy feature of DB2 on the iSeries, but I'm wondering -- it's kind of an oddball feature to the rest of the world, and SQL doesn't play with multiple members very well (I don't think?), so is this a dangerous long term solution? I know there are other options -- I could give the users their own libraries and make a copy of the work file in each library, or I could add the user profile as a key to the work file, etc. -- but they all seem more involved than what I'm doing now. Should I just figure "if it ain't broke, don't fix it", or is that likely to be short-sighted?
Thoughts, anyone?
Mike Naughton
Senior Programmer/Analyst
Judd Wire, Inc.
124 Turnpike Road
Turners Falls, MA 01376
413-676-3144
Internal: x 444
mnaughton@xxxxxxxxxxxx
****************************************
NOTICE: This e-mail and any files transmitted with it are confidential and solely for the use of the intended recipient. If you are not the intended recipient or the person responsible for delivering to the intended recipient, be advised that any use is strictly prohibited. If you have received this e-mail in error, please notify us immediately by replying to it and then delete it from your computer.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
