This is a basic issue that comes up frequently. I'll restate some
obvious points and tell you what I feel is the best approach to handle
this.
A user of a browser expects, by convention, to be able to select a
links/buttons concurrently. Servlets/JSPs must deal with this in general
and in particular they need to insure that they serialize access to back
end services that don't support concurrent requests. The typical
mechanism used is a synchronized service helper class instance stored in
the web components HTTP session state. More complex solutions involve
detecting and rejecting misordered requests.
Stateful EJB's are one such non-concurrent service, others are DBMS
connections, etc. So this is a typical impedance matching issue between
the web and back end services; and, there is a typical solution that
involves a bit of programming by the web component developer.
As was noted by several posters, resolving this by requiring stateful
session EJB to handle concurrent requests would significantly complicate
the EJB programming model. Ideally, the web or EJB container could
transparently provide the serialization; however, this is difficult to
do in a way that leads to 'correct' results in many cases. It appears
this is a clash between the web and business component worlds that the
web component developer is the one in the best position to sort it out.
Graham Parsons wrote:
>
> 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".
