Hi,

     I'm sure this is going to sound odd, but is there any way for an
entity bean to push an event to a client?

     Suppose I have a large hunk of data - say an XML DOM - that a lot
of my servlets are going to want to get their hands on.  However, the
servlets may also need to change the data.  I see two obvious
approaches:

     keep the data in an entity bean and encapsulate the data with
          accessors to perform the necessary operations on the data,

     provide a remote method that pulls the large chunk of data down
          and have the servlet request the entire data, use it, and
          if necessary make changes, and push the changed version back.

     Neither of these quite works for my needs.  The first approach
the EJB standard approach (if I understand EJb correctly) but it
assumes a static or at least fairly stable application.  The second
approach involves huge amounts of network latency and serialization/
deserialization overhead for each request.

     An alternative that occurs to me is to have a singleton client
that lives in each servlet JVM and fetches the data, keeps a copy on
hand, and hands out references to it(*).

     The client singleton would have to check with the EJB constantly
to make sure it has up to date data, and flush changes immediately
back to the EJB.  This would probably be sufficient, but it'd be even
niftier to have some way to push change events from the EJB out to the
client.  Is this possible?

(* With a complex data structure - a set of objects, - the servlets
   would, of course, have to be careful not to hang onto references
   that might become stale, but that's true for any of these
   approaches. I don't see any way around this isssue).

Steven J. Owens
[EMAIL PROTECTED]

===========================================================================
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".

Reply via email to