>
> TopicSubscriber subscriber = session.createSubscriber(topic);
> connection.start();
> Message m = subscriber.receive(); // !!!
My main complaint with the synchronous operations oriented EJB technology
has to do with plain 'ol robustness. ... like where is it ... ??
How can javasoft, EJB spect writers et al, call 100% synchronous / blocking
APIs robust? Where even the new JMS integration is following the EJB API
philosophy of not supporting timeouts, or some other (any) means to detect
on the server side hung or too long APIs.
IMHO the DD parameter of timeout that gets applied to just tranasactional
method calls is not sufficient. For one, it applies to all transactional
method calls, without regard to the BOM / usecase in effect and it only
affects transactional methods... I want the above subscriber.receive() to
be a non-blocking call. I could live with a blocking with given timeout
API. I would prefer a call back technology.
Generally I'm hearing others ask and compain about the synhronous nature
of the EJB spec, and that app server vendors aren't providing (proprietary)
solutions.
Are there any patterns that add robustness to a client getting hung in an
EJB non-transactional method. I.E. client stateless session bean calling
method doIt() on another stateless session bean. How can I protect the
first session bean from hanging, given that I can't create a timer
thread to timout the call to SB #2 ??
curt
Curt Smith
Z-Tel
email: [EMAIL PROTECTED]
work: 404-237-1166 x182
FAX: 404-237-1167
===========================================================================
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".
