I misread your requirements. I thought you were talking stateless.
In your case, you can simply mutex on the stateful session bean itself:
synchronized(aBean){
aBean.someMethod(); // ...
}
However this only works if the bean reference is stable. More than likely
though, you won't have this. More than likely you will be storing a handle
for your bean in http session state, and re-instantiating the bean referece
on the fly. Therefor perhaps you could synch on the handle instead of the
bean.
A third alternative is to Not use Stateful beans, but use http session state
for session state management, and use stateless beans for your services
layer. IMHO this is a better approach.
Regards,
-Chris.
> -----Original Message-----
> From: Graham Parsons [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, May 11, 2000 11:21 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Queuing requests to a Session Bean
>
> Chris,
>
> I don't see how a pool would help our case. We are effectively trying to
> either stop the client issuing two requests or ensure that they are both
> processed.
>
> All requests are aimed at the same STATEFUL session bean. How would a
> pool of stateless help us (even if they subsequently got a reference to
> the stateful bean, they still have to somehow queue the messages - I
> assume that a EJB-EJB call within the container is treated as the same as
> a client-EJB call across the container boundary as far as single method
> invocation at any one time is concerned).
>
> Cheers
>
> Graham
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Chris Raber
> Sent: Thursday, May 11, 2000 3:38 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Queuing requests to a Session Bean
>
>
> Create a pool of stateless session bean references in your client. An
> example pooling mechanism is in the Developer's Guide that you can get
> from
> our web site. It it open source...
>
> Regards,
>
> -Chris.
>
> > -----Original Message-----
> > From: Graham Parsons [SMTP:[EMAIL PROTECTED]]
> > Sent: Thursday, May 11, 2000 7:12 AM
> > To: [EMAIL PROTECTED]
> > Subject: Queuing requests to a Session Bean
> >
> > Are there any suggested design patterns for queuing multiple requests to
> > the same Stateful Session Bean (in order to avoid the exception because
> > Session Beans can only handle one request at a time).
> >
> > We are in an HTML - JSP - Java - EJB environment and the user is
> clicking
> > more than one button at a time - both of which send a request to the
> same
> > session bean.
> >
> > We could use:
> >
> > * JavaScript to disable the buttons once one is clicked
> > * Trap multiple clicks in the JSP or Java layer and queue (synchronise I
> > presume on a common method)
> >
> > Neither is very attractive as we are being code intrusive and I just
> > wondered how others had got around this problem.
> >
> > Thanks
> >
> > Graham
> >
> >
> ==========================================================================
> > =
> > 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".
