Assaf Arkin wrote:
>
> > Absolutely. I second the motion. I particularly endorse an API that
> > treats thread creation as its own thing, and doesn't try to make it
> > conform to more generic constraints. Threads are unique.
> Mark is on this list, so maybe he would like to open up a JSR for
> specifying thread beans.
(Personally I'd make it an operation on, say, EntityContext or
SessionContext or something like that--i.e. make it a basic Container
API since threads are a unique sort of beast different from other sorts
of resources that might be managed--but that's a minor difference.
What's important is that *some* Thread API exist *somewhere*, whether as
a bean or as a Container service.)
> > And no, I don't believe that the answer is just "use JMS wherever you'd
> > use a thread". That solves some problems, but not all of them.
> I totally second you on that. JMS is ultra useful, but just doesn't
> solve the problems you're dealing with (nor many other developers on
> this list).
Let's say it again loudly enough for Mark to hear. :-)
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".
