Aravind Naidu wrote:
>
> 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.
I bet Encina allows you to associate your threads with a transaction,
and doesn't attempt to control their lifecycle.
> 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.
It can be done, but it needs some additional APIs, way more specs and
documentation.
Complex issues like that tend to fail not when you develop the code and
run it, but in production environment. And as they say, YMMV. I could be
running an application using threads for years without a problem, give
it to you, and ten days later it breaks.
To avoid that you need very good documentation upfront.
Also, once you add threads people will be asking for transactional
control, security context and more features than the EJB 1.1 lacks.
So someone has to beat Sun on the head, say there are many people out
there requesting these features, figure out how to make them work for
2.0.
arkin
>
> -- 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
--
----------------------------------------------------------------------
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".
