I would store the state ( or aggregated data ) into a POJO and pass that
to Client B (using RMI or JMS - message driven beans).
--- scenario ---
1. Client A retrieves data from 3 database.
2. Client A builds POJO using data from step 1.
3. Client A passes POJO to Client B (using RMI or JMS).
4. Client B receives POJO and does its work.
5. Client B notifies Client A (RMI or JMS) that its work is complete.
6. Client A performs cleanup of POJO.
James
-----Original Message-----
From: An interest list for Sun Java Center J2EE Pattern Catalog
[mailto:J2EEPATTERNS-INTEREST@(protected)
Sent: Tuesday, October 21, 2003 5:09 AM
To: J2EEPATTERNS-INTEREST@(protected)
Subject: Re: Can different clients access one same stateful session
bean?
For a Real-World Scenario:
Client A makes a request to three distributed Databases, to which he has
Access: The Results are aggregated and stored in the
Stateful-SessionBean. He than passes the handle to this Bean to Client
B, who does not have access to the three Databases, but to the
aggregated and anonymised Data stored in the Stateful SessionBean.
Replace "Stateful Session Bean" with Data Grid Service and you get a
very common Scenario in OGSA-DAI, a Grid Standard to access federated
Databases. (http://www.ogsadai.org.uk/).
Storing things in the Database either introduces serious overhead (if
you stream your object-Structure into a blob) or is not maintainable (if
you try to map your Result-Structure to different Tables) - so in terms
of Maintainability and Speed, some notion of a Shareable Object-Cache
would be nice (and this is where the difference between stateful-Session
Bean and a Bean-managed Entity Bean, that never gets persisted become
blurry...)
Has anyone tried to implement this approach using ObjectDatabases in any
way? Or even Prevayler (http://www.prevayler.org/)?
cheers
stf
Anand Raman wrote:
> I think james is correct. Under what circumstances would anyone like
> to reuse the remote instance of a stateful session bean. By there very
> defintion a stateful session bean should be responsible maintaing the
> client state of only one client.
>
> If it for academic interest I can consider the scenario.
>
> anand
>
> ----------------------------------------------------------------------
> --
> *From:* An interest list for Sun Java Center J2EE Pattern Catalog on
> behalf of BOWMAN, James
> *Sent:* Mon 10/20/2003 2:43 PM
> *To:* J2EEPATTERNS-INTEREST@(protected)
> *Subject:* Re: Can different clients access one same stateful session
bean?
>
> I would strongly advise against using stateful session beans for this
> scenario. You would be better to pass a plain old java object in the
> event to Client2.
>
> Alternatively, use a stateless session bean. You could then allow the
> shared data to reside in a database and access it via entity beans.
> Then you could pass the primary key in the event from Client1 to
> Client2. So that the logic contained in the stateless session bean is
> working from the same data.
>
> -----Original Message-----
> From: peng wang [mailto:wp0@(protected)]
> Sent: 18 October 2003 03:04
> To: J2EEPATTERNS-INTEREST@(protected)
> Subject: [J2EEPAT-INT] Can different clients access one same stateful
> session bean?
>
>
> Hi,
>
> Image a scenario like this: there is a client, C1,
> accessing a stateful bean, SB. C1 does some operations
> on SB and then C1 sends an event to another client,
> C2,
> the remote ojb reference of SB is carried in the event
> (C2 and C1 are in different machines).When C2 receives
> the event, C2 get SB reference from event and C2 also
> does some operations on the same SB, after that C2
> send a noticing event back to C1, on receiving the
> noticing event C1 then removes SB and done.
>
> Is the scenario able to realized by using stateful
> session bean? if not, which mechanism should be used?
>
> thanks in advance!
>
> wp
>
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Shopping - with improved product search
> http://shopping.yahoo.com
>
> ====================================================================
> Companion Site: http://www.corej2eepatterns.com
> J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
> List Archive:
> http://archives.java.sun.com/archives/j2eepatterns-interest.html
> Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
> listserv@(protected)
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.525 / Virus Database: 322 - Release Date: 09/10/2003
>
> ====================================================================
> Companion Site: http://www.corej2eepatterns.com
> J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
> List Archive:
> http://archives.java.sun.com/archives/j2eepatterns-interest.html
> Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
> listserv@(protected)
>
> ====================================================================
> Companion Site: http://www.corej2eepatterns.com J2EE BluePrints:
> http://java.sun.com/blueprints/corej2eepatterns List Archive:
> http://archives.java.sun.com/archives/j2eepatterns-interest.html
> Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
> listserv@(protected)
====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive:
http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
listserv@(protected)
====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
