> >
> >
> > I agree.
> >
> > But what is the specific bindning to JMS request/reply? Isn't
> > your statement valid for any processing that takes place
> > within an EJB transaction?
>
> No specific binding. However, JDBC latency is a matter of performance,
> resources, and optimization. JMS latency is in the application domain - if
> the sending side of the application does not send a message, the lateny is
> equal to the timeout period.
Yes, but the scenario is to call a service that is implemented as a server in a JMS
request-reply senario - i.e. the responder to the request consumes the request message
and sends a response message in the same thread of execution. With other words: we are
discussing service request as stated in section 6.14 ("Request/Reply abstraction") of
the JMS spec.
> Specifying a timeout of, say, 60 seconds, can
> ruin you whole day (as well as your thread pools).
>
> >
> > Your DBA will but up a max cost for your jdbc calls. If your
> > JDBC call times ut, you will have to take some action (or the
> > dba has to). The same applies for the "synchronous"
> > utilization of JMS.
>
> Only if you guarantee the messages will be there. JDBC does guarantee a
> response. Latency is a matter of tuning.
>
> >
> > Could I interpret your statement like this:
> >
> > A container must be in charge of controlling the over-all
> > response time of the initial client request. This requires a
> > protocol between the container and the (synchronous) protocol
> > implementation. When using JMS in the fashion initially
> > suggested, we lock out the container from sending time-out
> > requests, since the lattency is visible to the container -
> > i.e. there is no target for a container-generated time-out request.
> >
> It's not what I had in mind, but I agree with it.
>
>
> > The container could have the possibility of such control only
> > if the resource manager was enlisted to the transaction
> >
> > Den 5 Jul 2001 skrev Avi Kivity:
> >
> > > >
> > > > I do not see any problems with 1)
> > > >
> > > > I think it is appropriate to use JMS in a request/reply
> > > > scenario with a
> > > > session bean as a client, given that you call receive on your
> > > > TopicSubscriber with a time-out value that is in the spirit
> > > > of synchronous
> > > > OLTP requests.
> > > >
> > > > Ian, what difference does it make, to invoke a jdbc call
> > > > blocking for 10ms,
> > > > compared to invoke a JMS receive call blocking for 10 ms? One
> > > > could even
> > > > argue that JMS gives you a portable way of controlling
> > > > request time-out,
> > > > whereas jdbc doesn't.
> > > >
> > > > /Johan
> > >
> > > If an EJB blocks for too long, throughput will be affected
> > considerably.
> > >
> > > Consider a server with N threads. Each EJB call blocks for
> > Tb seconds and
> > > utilizes Tc seconds of CPU time.
> > >
> > > CPU utilization is then limited by N*Tc/(Tb+Tc). If this
> > number is smaller
> > > than the number of CPUs on the machine, the server will be
> > underutilized.
> > >
> > > It is clear that if Tb (blocking time) is large relative to
> > Tc (processing
> > > time), then there will be a utilization problem, or the
> > number of threads
> > > will have to be increased dramatically, creating memory pressure.
> > >
> > >
> > > - Avi
> > > --
> > > This signature intentionally left blank.
> > >
> > >
> > ==============================================================
> > =============
> > > 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".
>
===========================================================================
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".
