> I was just at Java 1. A Gemstone speaker was saying that having session
> beans represented a serious architectural flaw and a barrier to scaling.
>
> Does anyone have information on the problem and alternatives when tracking a
> users state is critical?
I am no expert. However, I think the issue involved here is that sessions are
tied to a specific host's servlet engine. For scalability, one of the common
requirements is clustering. However, if the user can hit any server in a cluster,
then the session bean may not be in that servlet engine. To correct this, you
must persist the session across all servers in a cluster (I mean to say, put
the session in some place that is accessible to all servers). This adds some
overhead, which may be what the speaker was referring to.
On the other hand, it seems to me that you can just put an "id" of some nature
in the user's cookie (or URL), that you can use to access the "session", but
the session would come from EJB as opposed to from the servlet.
tim.
===========================================================================
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".
