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?
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.
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.
/Johan
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".
