<rave>
The difference is that before you were writing server side JavaBeans
which did not benefit from a TP monitor (performance, realibility,
integrity, security), and could do anything you want.
Now you're writing Enterprise JavaBeans which do benefit from a TP
monitor, but are also subject to the strage way of life running inside a
TP monitor.
Hard to adapt for Servlet/Java developers, very easy for those who did
TP monitoring in the past (mostly UNIX and Mainframe).
</rave>
arkin
Aravind Naidu wrote:
>
> I couldn't agree with you more.
>
> <rant>
> But the fundamental difference is that earlier it was just not a good idea
> to do these things (you took the risk).
> But, now everyone is stopping you from doing these things....
>
> So, that little esoteric app. that needs to be fitted in to the whole
> "architecture" needs to be fitted in elsewhere or under a different
> scenario. Thus a simple thing as a n logging audit trail (which for some
> stupid legacy reason has to be done to a flat file) has to be rearchitected
> to log to JMS and a separate utility written to take stuff off JMS and into
> the flat file... Sigh!!
>
> </rant>
>
> -- Aravind
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Zerbe John W
> Sent: Wednesday, 23 February 2000 08:38
> To: [EMAIL PROTECTED]
> Subject: FW: Threads question
>
> 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".
>
> ===========================================================================
> 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".
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
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".
