Only if it is the server which has the onus of assuring message delivery.
Via a blocking registration pattern where the client spawns a synchronous
thread, you completely avoid the impact on the server in handling the
message delivery. In essence the clients can pull the information in their
own threads and the onus of message delivery is with the interested party,
the client, and not the server.
Dave Wolf
Internet Applications Division
Sybase
----- Original Message -----
From: "William Louth" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, November 22, 2000 10:22 AM
Subject: Re: Alternative to EJB Callbacks
> 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".
>
>
===========================================================================
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".
