Robert,
The problem with callbacks is that your servers performance is now affected
by your clients performance in handling the callback invocation i.e.
synchronous communication. Typically your client will not be on running on
the same hardware specification than your appserver though it probably
doesn't have the same load. Whereas currently it takes 20 seconds to perform
the task it could end up alot higher. You need to break this coupling i.e.
decouple. Some of the ways to do this include using JMS or some event
service like CosEvents and posting a message/event on the status on the
operation. You have some flexibility with the implementation of this in both
JMS and CosEvents.
Another option off the top of my head could be to use an entity bean to
handle the communication between session bean and client. In this case the
client could provide some id to the session bean that would be used to
create an Progress entity bean that the session bean would write too i.e.
setData(50,"Current Phase:......") where the first parameter is the
percentage of the task completed and the the second is the message to
display. The client would periodically poll for the status of the task
through some other session bean providing it would the id of the task. The
polling from the client could be tuned in line with the users feedback
requirements and possibly customized by him/her. At the end the session bean
executing the task would remove the entity bean. The bean could even be used
to cancel a long running transaction if at certain phases in the session
beans execution it check the progress beans status field. The client could
cancel the operation through a session bean that updates the entity bean
status falg with something like 'abort' or 'cancel'.There is still
performance problems since you do need to make the event persistent and some
messaging implementations bypass this and offer non-guaranteed delivery for
the sake of better performance and throughput. Note you will need to run the
update on the progress entity bean with another transaction than the session
bean.
I am sure somebody out there has probably implemented something similar,
much more generic and sophisticated, in beta form but open-sourced.
Having said all of this I think a transaction taking 20 seconds is not
typical of the usage of Enterprise JavaBeans could you tell us more about
this. There might be other ways to solve this problem than the above
mentioned and at the same time reduce the turnaround. With 20 seconds you
will increase the likelihood of collisions with other transactions. The
holding onto the database resource can limit your scalability and increase
the work load for your database server since it will need to use large
amounts of memory storage to support the transaction requirements.
regards,
William Louth
Borland/Inprise
www.inprise.com/appserver
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Robert Hargreaves
Sent: Tuesday, November 21, 2000 8:07 AM
To: [EMAIL PROTECTED]
Subject: Alternative to EJB Callbacks
Hi all,
We have a requirement in out application where need to continually update a
progress bar on the client screen whilst the EJB App Server performs a task
(a single remote method call to a stateless session bean) which lasts about
20 secs. The ideal way to do this would be to use a callback method that
updated the client at regular intervals, say every second, from the session
bean. This can be done with standard RMI but our app server has its own
version RMI that means we can't do this.
What other alternatives are there to callbacks. I've read somewhere you can
get similar functionality with EJB2.0 Message Beans and/or JMS, but aren't
these overkill for a progress bar?
Any help would be greatly appreciated,
Rob Hargreaves
===========================================================================
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".
