Grant for the moment that I understand all the issues around why you
can't create threads and run them inside enterprise beans, whether
session or entity.
One of the things I need to be able to do is construct "workflows" (ugh;
I hate that term) that are parallelized to some degree. For example, in
order to decide whether to order a bucket of widgets, a company first
has to make sure that the project for which the widgets are needed is on
schedule, has enough inventory to justify the bucket-sized order (I'm
making all this up from whole cloth in case it wasn't obvious), that the
warehouse is, uh, empty enough to hold the bucket of widgets, and that
the, uh, distribution network of trucks and things is available for the
length of time it would take to deliver the widgets. Only then can the
order go through.
Nevertheless, this can be seen as one big task, with all of the bizarre
checks as preconditions. There's nothing that prevents most of those
preconditions from occurring in parallel--then once they all complete
(or a sufficient number of them completes) the order can be placed. If
they complete badly, or there are errors, then of course the order is
not placed.
Ideally I'd love to be able to encapsulate this in a session bean. But
of course I can't (<vendor>except in WebLogic, thank God; yet another
reason I'm personally leaning that way</vendor>) start a raft of threads
working on these precondition tasks, join up with them when they're
done, and test their results. (Note that of course the creation of many
threads that perform what are essentially read-only checks and then join
up with the main one does not result in any transactional no-nos,
providing a nice counterexample to the "the EJB server must control all
threads" dogma.)
How then should I accomplish this task if I'm going to be specification
compliant? It looks like if I wanted to be a good EJB1.1 citizen, I'd
have to move each precondition step into its own session bean (eeeYUCK)
and call them all from a multithreaded client (double eeeYUCK)--the
client now becomes the place where the *real* workflow occurs (triple
eeeYUCK), not the session bean. This seems faintly or strongly wrong to
me (depending on how ornery I'm feeling at the moment). Comments?
Surely the EJB specification should allow for "workflows" like this.
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".
