You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Massimo <ml...@gmail.com> on 2005/03/07 14:39:57 UTC
Stateless app for a statefull gateway
One of my app is a web gateway for a information retrevial information
system which use a statefull protocol and maps resources one-to-one
with the connection, now i put a reference in the HttpSession for
reproducing the one-to-one mapping.
Now i would like to port this app to Tapestry as proof of concept and
a learning live example, and want to keep the webapp stateless.
Does the Global object sound a good place where to a Map for the
one-to-one association between web clients and (heavy) gateway client
?
Does that produce any real benefits from having this instead of having
my heavy client object stored in a HttpSession ?
I don't mind serialization and/or clustering issues in this case.
Thanks
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Stateless app for a statefull gateway
Posted by Massimo <ml...@gmail.com>.
On Wed, 9 Mar 2005 05:12:30 -0500, Erik Hatcher
<er...@ehatchersolutions.com> wrote:
> Learn something every day :) It's even mentioned here:
Mee too... thanks you for the hints.
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Stateless app for a statefull gateway
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
Learn something every day :) It's even mentioned here:
http://jakarta.apache.org/tapestry/doc/api/org/apache/tapestry/
IEngine.html#getGlobal()
But who reads documentation anyway?! :O (Actually I've read the
servlet specification several times digging for various tidbits
including how form-based authentication works and so on - and I
probably read that bit also and it didn't stick in long term memory).
Erik
On Mar 9, 2005, at 4:53 AM, Kent Tong wrote:
> Erik Hatcher <erik <at> ehatchersolutions.com> writes:
>
>>
>> application scope is not replicated in clusters? really?!
>
> Really. Excerpt from the servlet specification:
>
> SRV.3.4.1 Context Attributes in a Distributed Container
>
> Context attributes are local to the VM in which they were created.
> This prevents
> ServletContext attributes from being a shared memory store in a
> distributed
> container. When information needs to be shared between servlets
> running in a
> distributed environment, the information should be placed into a
> session (See
> Chapter SRV.7, “Sessions”), stored in a database, or set in an
> Enterprise
> JavaBeansTM component.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Stateless app for a statefull gateway
Posted by Kent Tong <ke...@cpttm.org.mo>.
Erik Hatcher <erik <at> ehatchersolutions.com> writes:
>
> application scope is not replicated in clusters? really?!
Really. Excerpt from the servlet specification:
SRV.3.4.1 Context Attributes in a Distributed Container
Context attributes are local to the VM in which they were created. This prevents
ServletContext attributes from being a shared memory store in a distributed
container. When information needs to be shared between servlets running in a
distributed environment, the information should be placed into a session (See
Chapter SRV.7, “Sessions”), stored in a database, or set in an Enterprise
JavaBeansTM component.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Stateless app for a statefull gateway
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
application scope is not replicated in clusters? really?!
On Mar 8, 2005, at 9:34 PM, Kent Tong wrote:
> Massimo <mlusetti <at> gmail.com> writes:
>
>> I would like to go further even if slightly off topic, sorry for that.
>> So from a servlet container scalability point of view there's no
>> difference between having and heavy fat object stored in the
>> HttpSession or in a "application global" Map ?
>
> If you use a cluster, the global map will not be replicated
> to the nodes, but the session will. This affects performance
> but gets you higher availability (do you want the customer to
> get disconnected if one of the node crashes?)
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Stateless app for a statefull gateway
Posted by Kent Tong <ke...@cpttm.org.mo>.
Massimo <mlusetti <at> gmail.com> writes:
> I would like to go further even if slightly off topic, sorry for that.
> So from a servlet container scalability point of view there's no
> difference between having and heavy fat object stored in the
> HttpSession or in a "application global" Map ?
If you use a cluster, the global map will not be replicated
to the nodes, but the session will. This affects performance
but gets you higher availability (do you want the customer to
get disconnected if one of the node crashes?)
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Stateless app for a statefull gateway
Posted by Massimo <ml...@gmail.com>.
On Mon, 7 Mar 2005 10:46:15 -0300, Marcus Brito <mb...@gmail.com> wrote:
> No, it doesn't. The global object is, well, global. A single instance
> is shared between all clients of your application. I think the best
> you can do is replicate the same strategy you used before: stuff a
> token or something that you can use to identify the gateway session in
> the Visit (Tapestry equivalent of HttpSession).
>
> Just keep in mind the visit object is stored in the session, and thus
> must be serializable. If you're running in a distributed scenario, you
> want to keep the visit object as small as you can. But since you were
> stucking your client objects in the HttpSession anyways, I guess
> serialization this isn't a problem for you.
Thanks for you hints.
I would like to go further even if slightly off topic, sorry for that.
So from a servlet container scalability point of view there's no
difference between having and heavy fat object stored in the
HttpSession or in a "application global" Map ?
Ciao
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Stateless app for a statefull gateway
Posted by Marcus Brito <mb...@gmail.com>.
> Does the Global object sound a good place where to a Map for the
> one-to-one association between web clients and (heavy) gateway client
No, it doesn't. The global object is, well, global. A single instance
is shared between all clients of your application. I think the best
you can do is replicate the same strategy you used before: stuff a
token or something that you can use to identify the gateway session in
the Visit (Tapestry equivalent of HttpSession).
Just keep in mind the visit object is stored in the session, and thus
must be serializable. If you're running in a distributed scenario, you
want to keep the visit object as small as you can. But since you were
stucking your client objects in the HttpSession anyways, I guess
serialization this isn't a problem for you.
-- Marcus Brito
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org