> -----Original Message-----
> From: Johan Eltes [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, July 05, 2001 18:18
> To: [EMAIL PROTECTED]
> Subject: Re: Sync client reqst to bean that uses async (JMS)component
>
>
> 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. 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".
