Re: Problem of multiple clients request concurrently 1 session stateful bean

Juan Pablo Lorandi <[email protected]>
Newsgroups gmane.comp.java.sun.ejb.general
Organization CodeFoundry LTD
Message-ID <000501c366b6$48e89930$0a00a8c0@rifle>
Solutions for this case compromise scalability & performance. You could
roll out your own solution, there's plenty of examples in Tenembaun's
white book. Building customized semaphores and mutexes would be part of
the solution, I guess.

Don't overlook the fact that throwing an exception when concurrent
access of a SFSB actually is a solution to your problem. Simply adding
code that retries the operation may be all you want. Again, that depends
on which context you're attempting this. Is your bottleneck (SFSB) by
choice? Are you using it as a DAO/Cache?

Juan Pablo Lorandi
Chief Software Architect
Code Foundry Ltd.
[email protected]

Barberstown, Straffan, Co. Kildare, Ireland.
Tel: +353-1-6012050  Fax: +353-1-6012051
Mobile: +353-86-2157900
www.codefoundry.com <http://www.codefoundry.com/>

Disclaimer:

Opinions expressed are entirely personal and bear no relevance to
opinions held by my employer.
Code Foundry Ltd.'s opinion is that I should get back to work.

-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[email protected]] On Behalf Of Le Quang Tu
Sent: Tuesday, August 19, 2003 6:27 PM
To: [email protected]
Subject: Re: Problem of multiple clients request concurrently 1 session
stateful bean


yeah , I see , the fork must be an entity. But I want to know there is
any other solution for this case

----- Original Message -----
From: James Hicks <mailto:[email protected]>
To: [email protected]
Sent: Tuesday, August 19, 2003 6:48 PM
Subject: Re: Problem of multiple clients request concurrently 1 session
stateful bean

It is against the spec for > 1 client to access a stateful session bean.
You will need to rethink your design.

James Hicks

-----Original Message-----
From: Le Quang Tu [mailto:[email protected]]
Sent: Monday, August 18, 2003 11:03 AM
To: [email protected]
Subject: Problem of multiple clients request concurrently 1 session
stateful bean


Hi all,

There is any solution to solving the problem of multiple clients request
concurrently one instance session stateful bean?
 For example for the well known dining philosopher example, . The
philosophers and the forks are designed  as session stateful beans. So
there
is the situation of  two philosophers use the same fork. It means 2
instance of SFSB philosopher request the same instance of SFSB fork and
the
EJB Container will throw the exception with the following message: "The
Session Bean are executing another request". It is normal according to
the
specification of EJB. However , I'am looking for the solution to solve
this
problem.

Could you guys help me or recommend me something on that?.

Best regards

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




===========================================================================
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".
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.