7 Replies Latest reply on May 24, 2006 9:19 AM by norman.richards

Why does Gavin say the http session is an inherently unscala

sgodden May 23, 2006 3:18 PM

Gavin, in the TSS interview you gave, I think you heavily promoted the use of SFSB, saying that they were scalable, whereas the HTTP session is an "inherently unscalable construct".

Please could you expand on that and explain in detail why one is scalable and the other is not, because I can't see it. They both conceptually do the same things wihch is to maintain state over mutiple requests. What is inherently different about the two paradigms?

1. Re: Why does Gavin say the http session is an inherently uns

gavin.king May 23, 2006 3:24 PM (in response to sgodden)

They are both the same construct in terms of scalability.

But one is broken. (The HttpSession does not implement dirty checking for mutable objects.)
Actions
2. Re: Why does Gavin say the http session is an inherently uns

sgodden May 23, 2006 3:29 PM (in response to sgodden)

Can you give me a sample use case where it goes wrong?
Actions
3. Re: Why does Gavin say the http session is an inherently uns

gavin.king May 23, 2006 3:31 PM (in response to sgodden)

Change an object while it is sitting in the session. The change does not get replicated.

(You are supposed to call setAttribute() again, but nobody ever does.)
Actions
4. Re: Why does Gavin say the http session is an inherently uns

gavin.king May 23, 2006 3:34 PM (in response to sgodden)

Anyway, there are other good reasons to use SFSBs - they just support waaay more functionality than a dumb JavaBean, and are just as easy to write.
Actions
5. Re: Why does Gavin say the http session is an inherently uns

sgodden May 23, 2006 3:38 PM (in response to sgodden)

Change an object while it is sitting in the session. The change does not get replicated.

(You are supposed to call setAttribute() again, but nobody ever does.)

Ah ok - whereas SFSB state is always replicated by the container at the end of the invocation? As a job lot? I guess it can't tell which instance variables you might have changed, so it has to replicate them all?

Anyway, there are other good reasons to use SFSBs - they just support waaay more functionality than a dumb JavaBean, and are just as easy to write.

Perhaps, but I'd just like to make sure I've understood your reasoning on the http session topic.
Actions
6. Re: Why does Gavin say the http session is an inherently uns

gavin.king May 23, 2006 4:08 PM (in response to sgodden)

In JBoss, SFSB is implemented on top of JBossCache, so it can actually do attribute-level replication.

Actually, not sure about JBoss 4, but in JBoss 5, the HttpSession actually does do dirty checking, even though this is not required by the spec.
Actions
7. Re: Why does Gavin say the http session is an inherently uns

norman.richards May 24, 2006 9:19 AM (in response to sgodden)

This is available in 4.0.4.

If anyone is interested, look for the parts on FIELD level replication for HTTP session: http://docs.jboss.org/jbossas/jboss4guide/r5/html/cluster.chapt.html#clustering-http-state
Actions

Go to original post