 | Mailing List | | Home | | Forum Home | | JBoss - Java Application Server | | Struts - A MVC web framework | | Tomcat - JSP/Servlet container | | iText - An open source PDF Java Library | | JDOM - JDOM XML Parser | | J2EE - A mailing list for Java(tm) 2 Platform, Enterprise Edition | | J2EE Pattern - An interest list for Sun Java Center J2EE Pattern Catalog | | Servlet - A mailing list for discussion about Sun Microsystem's Java Servlet API Technology | | JSP - A mailing list about Java Server Pages specification and reference | |
Struts & Hibernate
|
|
|
| | | Can different clients access one same stateful session bean? | Can different clients access one same stateful session bean? 2003-10-21 - By Stefan Frank
Back
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)
|
|
|
