See below.
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: Monday, February 28, 2000 2:52 PM
> To: [EMAIL PROTECTED]
> Subject: Re: jms & ejb
>
> ----- Original Message -----
> From: Bhattacharyya, Ana <[EMAIL PROTECTED]>
> > or rather when do u need asynchromous calls to a
> > bean. can anyone describe the situation where I may need such things.
> Also
> > which model is best suited for ejb -- the pub/sub model or the P2P
> model??
>
> Think of a workflow where four things need to all happen before the fifth
> one can. It does not matter how things one through four happen, or when
> they happen: it simply matters that they all occur, successfully or
> erroneously. Only then, let's say, can you do your fifth action.
>
> Since you cannot use threads in a session bean, you cannot, for example,
> inside a stateless session bean do actions one through four in parallel.
> You just can't do it. You must do item one followed by item two followed
> by
> item three. If each action could be done in parallel, and each action
> takes
> four days, then you can see that NOT doing them in parallel--i.e. working
> with EJB session beans--results in a terrible architecture.
[Zerbe John W] Do you REALLY want all resources touched within your
5 part transaction to be tied up for 4 days?!? In a workflow environment
doesn't
it make more sense to commit a "work request" transaction that initiates the
first 4 parts
of your operation asychronously by only "transactionally committing" the
request
messages to JMS as well as creating an Entity that represents the "work
request"
with its current phase of completion? There is nothing stopping each of
these 4
actions from publishing a "completion" message to a bean that will do your
5th operation
upon reception of the 4th completion message. This happens to invoke this
bean 4 times
instead of your once (while waiting for all your threads to complete) but
will keep the
individual transactions much shorter. Generally shorter individual
transactions scale better anyway
by keeping resources locked for shorter periods of time.
>
> This is a barn-sized hole in the EJB specification. The way that you are
> supposed to be able to get around this in the 2.0 specification will be
> via
> pub/sub messaging over JMS, where each action to be performed is
> essentially
> the publishing of a message to either another bean or a third-party
> program.
>
> In my mind this only solves some of the problems and completely ignores
> the
> simple multiplexing thread problem I presented earlier.
>
> 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".
