Hmmm!! I will have to disagree. I used to write (still do) services in
Encina (IBM/Transarc's TP monitor) and the only way to get decent
performance out of Encina was to use threading. Inherently Encina's model
encouraged usage of threads for asynchrouse rpc's.
It is hard to work with these restrictions, but as Sriram says in the other
post it should be documented as not a good idea for so and so reason and
left at that.
-- Aravind
<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".
