RE: Something lighter than a database file . . .

James,

I'm going to jump on the "two structures are needed" bandwagon.

1) (key'd or searchable) structure to hold the request keys already seen
to check for duplicates.
2) FIFO structure to hold the request

Correct me if I'm wrong but it seems as if once a request with a certain
key comes in, the key is never deleted even after the request is
processed.

For example:
Request #1 comes in, generates request 4,7,9
Request #1 processed,
Request 4, generates request 3, 5
Request 4 processed
Request 7 processed
Request 9 processed
Request 3 generates 1, 15, 16  

At this point, you don't put request #1 back on the FIFO queue since it
duplicates a request already seen.  At what point do you reset the keys
seen?  When the job is restarted?


This seems vaguely similar to the difficulties of traversing a
directories sub-tree when dealing with a file system that supports
symbolic, recursive links.

You may want to research that problem to see if there is anything that
would help you.

HTH,

Charles Wilt
--
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121
  

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx 
> [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of James H 
> H Lampert
> Sent: Monday, March 06, 2006 8:23 PM
> To: midrange-l@xxxxxxxxxxxx
> Subject: Something lighter than a database file . . .
> 
> Would anybody have any suggestions for something that 
> would:
> 
> 1. Be lighter than a temporary database file, preferably 
> living in memory, instead of on disk, and having less 
> overhead than a file,
> 2. Yet still be capable of expanding to contain whatever 
> data records are put into it,
> 3. While rejecting duplicate records?
> 
> We've got a server job that turns a single client request 
> for a sort of "mass dump" (cf. a SysEx dump in MIDI) into 
> a bunch of, shall I say, "simulated client requests," 
> storing them in a database file in QTEMP. The simulated 
> requests then run as a batch, with the results sent back 
> to the client as a single response. It's an improvement 
> over having the client generate the whole list of requests 
> as if they were being sent interactively, but we have 
> reason to believe the database file is bottlenecking the 
> process.
> 
> --
> JHHL
> -- 
> 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.
> 
>