Multithreading: was Java Vs RPG on iSeries -- JAVA400-L

Joe,

On Thursday 19 September 2002 14:10, you wrote:
> > From: Dieter Bender
> >
> > And now the java way to do this.
> > I have one java main job, this job opens up up to 16 connections to the
> > database, then the job splits into up to 16 threads, each thread
> > with its own
> > connection to the database (= Server job). Now I have 2 jobs per
> > cpu running,
> > doing my work. Thats the way o get more speed by adding a lot of
> > overhead. (I
> > don't want to discuss how to do this in rpg, maybe in another list). the
> > balance of work is easy scalable by using stored procedures, by
> > instance to
> > get workload to the database jobs.
>
> Yes, this is the parallel processing I was talking about in my response to
> Larry.

Thats the point: parallelism is the key to speed on multiprocessor boxes and
even on a single processor RISC box, its a performance issue.

> It certainly can be done, although it requires carefully designing
> the process so that the problem set is broken up into pieces, and that each
> job can do two things:

Its one way to split a process horizontal, but its possibel vertical too.
Horizontal means, to split 10.000 invoices into two parts of 5.000 and
process both sets parallel. Vertical means to split the process in several
parts (e.g. calculating prices, printing, ...) and process the parts in
parallel.

>
> 1. Mark a piece "in process"
> 2. Mark a piece "complete"
> 3. Get the next "unprocessed" piece

This could be a technic to process a horizontal splitted amount of work in
parallel. The arising problem to do the work for each "invoice" once and only
once, is synchronized by external markers. Using processes (I mean heavy
weight processes as as400 jobs) you need asynchronous synchronisation
mechanisms.

>
> This requires a view over the database that can react to changes from
> different jobs, like a logical view.  Before version 2.0, JDBC wasn't very
> good for creating dynamic views over the database, but now you can create
> scrollable cursors that reflect changes by other jobs.

In a multithreaded environment you can use shared data between the threads to
synchronize the parallelism.
The horizontal version: you have one controlling thread, this process fetchs
an invoice and just starts the processing in a new thread, then the next
invoice and so on. you can configure how many threads to open, if one is
finishred another is started. You don't need any markers, DTAQS or other
external data, all is handled in the main thread, using shared data to the
other threads.
Now you have a number of threads, but you are using only one processor,
because all is running in the same job (=JVM). So far you have no benefit of
additional parallelism. Next step is, that every working thread has to
delegate its work to another job (might be JVM or a Database Server Job
QZDASOINIT) doing the real working and waiting to get the needed results back.
Here you can use stored procedures, to get the work to the database servers
(might be a sort of mixed approach: use java to speed up rpg or COBOL), or
you can use EJBs for instance.

the vertical version works in a similar way.

>
> Once you've done the above, though, this sort of approach will definitely
> help batch jobs.

To use this technique, you have two requirements:
1. Multithreading, to split a workload in parallel transactions
2. an application serving mechanism to put the workload to another processor
(or even box!!!)

1. Multithreading:
definitly impossible for OPM and 5250 (and therefor 5250 will die), you don't
need a gui, but you really need Multithreading in a modern user interface.
(more than one window activ at the same time)
For ILE only possible for C. Using RPG or COBOL you have to use *SERIALIZE,
which in fact disables parallelism, by synchronisation.
2. Application Server:
Multiple connections to one database possible for java, impossible for
embedded SQL in COBOL or RPG, SQL CLI I don't know; I didn't do that up to
now.
In Java you can use EJBs and it depends on the container, wether it can
spread it over multiple JVMs. Maybe that using WebSphere needs the enterprise
edition, not available for AS400 (<flame>WebSphere is no strategical product
for as400 - as long as the full version of Websphere is not supported!
</flame>)
In a traditional environment CORBA could be a solution (<flame>AS400 is no
strategical product for ibm - as long as CORBA is not allowed to run on
as400</flame>). Another approach there is MQ Series, but MQ series compared
to EJBs, I suppose that EJBs will be faster and they will be faster in near
future definitely.

> The only problem then is having enough disk arms,
> something the iSeries USED to very good at, but which IBM seems to be
> moving away from in favor of larger, cheaper drives.  But that's a
> different story.

Nice game: solving a problem with one bottleneck, the next bottleneck arises.

> > I must confess, that my first statement on this was a little bit
> > provocative,
> > but thats the only way to get attention for this.
>
> That's okay, you certainly managed to get the list buzzing!

I try to do my very best. (excuse my limited english, its not my native
language).

Dieter

> We haven't had
> this much discussion in a long, long time, and I think it's all good
> discussion.  We even managed to get Blair and Larry chiming in, which is
> fantastic!
>
> Joe
>
> _______________________________________________
> This is the Java Programming on and around the iSeries / AS400 (JAVA400-L)
> mailing list To post a message email: JAVA400-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l
> or email: JAVA400-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/java400-l.

--
mfG

Dieter Bender


DV-Beratung Dieter Bender
Wetzlarerstr. 25
35435 Wettenberg
Tel. +49 641 9805855
Fax +49 641 9805856
www.bender-dv.de