Re: Callable statement with RPG

I keep noticing that a lot of problems mentioned in here might be solved
with something I have pursued, but not deployed seriously.  Still, I think
it would work well, especially for the current "multithreaded" discussion
and would generally ease the burden of the newly-converted RPG programmer.

What I'm about to suggest may be a symptom of too much time on the Linux
side of it of late, but on a small scale, I have done approaches like this:

class myservlet implements Httpservlet { // all this from memory, probably
"spelled" wrong

   void doGet(stuff. .. ) {
      myservletshadow me = new myservletshadow(stuff. . .);
      me.run();  // moves the servlet work to the shadow object
   }
}

class myservletshadow extends Object {
    Stuff stuff;   // single-threaded, invocation local data

   myservletshadow(Stuff stuff...) {
      this.stuff = stuff;  // etc.
  }

    void run() {
    // do the servlet invocation work, including writing the output stream
   }
}

It seems to me that there is much appeal in it.

1.  It gets rid of all the multi-threaded aspects of the servlet
architecture.  While myservlet's data (if any) has multi-threaded problems,
myservletshadow has no such problems.  After all, when doGet gets control
for a given browser request, it is still only one thread.  If it gets its
own per-invocation object, that would be single threaded.  Moreover, as an
actual Java object, it would largely have the look-and-feel of the usual
static programming model RPGers know and love so well, with the instance
data being static-like in practice.

2.  There is still the question of how best to synchronize with RPG and the
underlying data base.  The system may not know, in particular, that you are
logically single threaded.  But, at least you have moved the typical
servlet coding back to more familiar territory.  If the "new" on every
browser invocation is too much in terms of objects floating about, then one
could use a Vector or something to have a limited "hot list" of
to-be-reinitialized objects waiting around from previous completions
without any serious changes to the above.

Is anyone else doing this?


Larry W. Loen  -   Senior Linux, Java, and iSeries Performance Analyst
                          Dept HP4, Rochester MN