Boy, the more things change, the more they stay the same!
<rant>
These same issues have been around for decades. For those that remember,
there was COBOL on things called mainframes. People wrote COBOL programs
that opened files, read and wrote records (easy to do, built into the
language) and built 3270 screens in TSO. People then discovered that their
applications didn't scale beyond 10s of users. Then came the early TP
monitors. The files that the programs needed became RESOURCES to the TP
monitors. The TP monitor could then OPEN the file once, then do all of the
I/Os on the files on behalf of the programs caching those that were accessed
most often. These TP monitors could preload application programs and manage
the screen I/O. These applications could then scale up to support hundreds
then thousands of users. It took a while for some application programmers to
realize that even though file I/O was BUILT INTO THE LANGUAGE, they COULDN'T
USE IT! They actually had to make program calls to the TP monitor to get and
update file records instead of just using the COBOL READ verb! My point to
all of this is that these seemingly rediculous restrictions (from the
application programmer's perspective) are there for very good reasons.
</rant>
There, now I feel better.
John Zerbe - Mellon Bank
Information Technology Solutions - Middleware Team
Phone: 412-234-1048 E-Mail:[EMAIL PROTECTED]
> -----Original Message-----
> From: Laird Nelson [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, February 22, 2000 11:59 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Threads question
>
> Eric Williams wrote:
> > And the EJB specification writers had to enable vendors to offer
> > advanced
> > products based on the specification (eg, EJB implemented *in* a
> > database, or a
> > multi-VM shared-memory approach, etc.)... some of which are incompatible
> > with
> > threads or file I/O.
>
> Something here bothered me and I just got it: if java.lang.Thread is
> part of the core Java language (as implemented by every VM, including
> Oracle's "advanced product" in-database VM), then how could you have an
> "advanced product" that is incompatible with it?
>
> Cheers,
> Laird
>
> ==========================================================================
> =
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
