Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

ServletContext is not distributable...

 
Gennady Shapiro
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
According to the spec ServletContext is not distributable. So what's the point of ServletContext.get/setArribute?
I mean, if you set an attribute into ServletContext there is no guarantee another user will ever get it. What is the purpose of attributes in ServletContext??? I see no logic in this.
Anyone?
P.S. The answer "to pass objects between servlets within 1 session" is far fetched, you have a Session for that.
P.P.S. I know some app servers make ServletContext distributable despite what Sun says about it.
 
Manjunath Subramanian
Ranch Hand
Posts: 236
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Attributes set in servletcontext is accessible to all servlets in a web application.This is particularly useful when you have a situation where some of the servlets are not part of a session or don't need to maintain session.
So small peices of information which needs to be shared by all servlets in a web application can be set in servletcontext object.
Hope this helps,
Manjunath
 
Axel Janssen
Ranch Hand
Posts: 2166
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
... and attributes in ServletContext scale much better. You have one ServletContext per WebApp, but you have one Session per user.
If you have 100 active usersessions on the site, you have 100 session - objects (with all its attributes 100 times), but just 1 ServletContext.

Axel
 
Madhav Lakkapragada
Ranch Hand
Posts: 5040
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you don't mind...there's a little more to this than what is already said.....
Attributes set in servletcontext is accessible to all servlets
...accessible to all servlets, JSP (which can be considered servlets), Beans, Custom Tags, Listeners etc which are defined in the application.
You have one ServletContext per WebApp, but you have one Session per user.
A session is NOT necessarily restricted to ONE USER ONE SESSION. No, its basically more like a bunch of requests that you want to aggregate. As a user, I can start the web-app from IE get a session, then start the same web-app from NS and get one session. One use can have more thatn one session. Also, using the same browser, you can create many sessions - check with More Servlets & JSPs for an example on this.
Just clarifying...........
- satya
 
Axel Janssen
Ranch Hand
Posts: 2166
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Madhav Lakkapragada:
Also, using the same browser, you can create many sessions - check with More Servlets & JSPs for an example on this.
Just clarifying...........
- satya

Dont have More Servlets. How do I do that?
With opening a new browser window by clicking on the browser icon and not by File/New/Window?
For me these are problems with sessions-over-http in general. You don`t have any easy opportunity to shield your app against that?

Just asking......
Axel
 
Madhav Lakkapragada
Ranch Hand
Posts: 5040
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry for being lazy , should have explained earlier itself (but then again I din't want to deviate off the original subject)

The simplest way to do this is to disable cookies in your browser and access a framed page that loads the same JSP page multiple times.

The following three source code files were used in the book to explain the concept...its simple
a Test page with multiple frames loading a JSP which instantiates a Bean.
regds.
- satya
P.S:
Use RMB -> Save Target As to download the source files.
P.P.S:
Did you know Cookies is the default mechanism for Session Handling? That was news to me as I was expecting it to be App Server specific. :roll:
- satya
 
Axel Janssen
Ranch Hand
Posts: 2166
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We surely hijacked this thread and directed it to a very distance place. I am very sure that Gennady was referring to multiple servers for load balancing/failover environments:
Originally posted by Gennady Shapiro:
According to the spec ServletContext is not distributable. So what's the point of ServletContext.get/setArribute?
...
P.P.S. I know some app servers make ServletContext distributable despite what Sun says about it.

In that case the fact that ServletContext is not distributable is an issue, if you don't use it for global read only system settings (as for example database connections, path-settings to files, etc.)
If ServletContext is not distributable updates on the attributes during runtime will not be reflected on all servers. This is an issue.
Satya: I will respond to your points later.
Axel
[ February 24, 2002: Message edited by: Axel Janssen ]
 
Gennady Shapiro
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks all , but:
1. Manjunath, the essence of the problem is the fact that you cannot share small pieces of info between all servlets in Web application. The spec says use JDBC, JNDI, etc for that.
2. Axel, I would nornally agree with your estimate on scalability, however, while not all servlets are guaranteed to get access to your info in ServletContext others can certainly override and you lose your info. Use must use Session to protect your state data. Of course, you can store your data in ServletContext based on sessionId key , but then again, it becomes collocated to 1 server of a cluster and your session state comes out of sync.
3. Madrav, , while you are a single physical entity with many browsers, the server considers a new connection (isNew()) a separate client. In other words, the server sees every new browser connection with no session id as a new user. But this is besides the point. The problem is you cant share data between these users via ServletContext.
4. Axel, yes, this problem remains. And it seems to me that it's too large of an issue to simply overlook. What Sun was thinking about when they made ServletContext not distributable??? I mean if an application exist in a cluster it should synch its state acroos cluster just like user session does...who wanna bet they'll make it distributable in spec 3.0 or sooner?
[ February 24, 2002: Message edited by: Gennady Shapiro ]
 
Madhav Lakkapragada
Ranch Hand
Posts: 5040
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

According to the spec ServletContext is not distributable. So what's the point of ServletContext.get/setArribute?
I mean, if you set an attribute into ServletContext there is no guarantee another user will ever get it. What is the purpose of attributes in ServletContext??? I see no logic in this.

Okay, let me try one more time...............
ServletContext.......user........session.....

if you set an attribute into ServletContext there is no guarantee another user will ever get it

Yes there is. When you set an attribute on a ServletContext, it is available through out the application. Hence, another component (servlet, JSP, bean, listener etc) in the application can use the getAttribute(...) and get the value of the attribute.
Now let's call this feature "sharing" inside the application (which is a ServletContext) for all we care.
Hence, when you setAttribute(...) on the ServletContext, using the getAttribute(...) on the ServletContext, another user (in another session) running the same application CAN getAttribute(...) and see the value.
Regarding the "distributable"......this term is used to convey that the Application (ServletContext) can share data with another Application (ServletContext). This is what according to the Spec is prohibited.
A user running Application1 "cannot" and "must not" be allowed to see the values of an attribute from another application say Application2 using the getAttribute(...). If such a exchange of attributes is needed by either of the applications, then the use of JDBC or JNDI or whatever should be used. The App server must provide this behavior (preventing of shared attributes between applications).
In conclusion.............
So, your subject line is true. But, your body of the post is a llittle confusing and may not be true.
Personally, I don't think this is an oversight. It is required and intended behavior specified in the Specs.
Hope I am clear.........any comments please.
regds.
- satya
 
Axel Janssen
Ranch Hand
Posts: 2166
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Madhav Lakkapragada:
[QB}
Regarding the "distributable"......this term is used to convey that the Application (ServletContext) can share data with another Application (ServletContext). This is what according to the Spec is prohibited.
- satya[/QB]

I think that Gennady is talking about apps which run in a multiserver environment (server clustering) for loadbalancing/failover.
This is an often repeated point for example in the IBM WebSphere documentation. If in these circumstances changes in a ServletContext in WebContainer of ServerA are not propagated to WebContainer in ServerB (both in the same cluster) Gennady has made an important point.
At least you could use ServletContext for global configuration settings (for example to initialize DataSource-Objects). But you can`t savely change the value and expect that all WebContainers of the app reflect this change.
I am not sure.
Axel
 
Madhav Lakkapragada
Ranch Hand
Posts: 5040
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

If in these circumstances changes in a ServletContext in WebContainer of ServerA are not propagated to WebContainer in ServerB (both in the same cluster) Gennady has made an important point.

I agree that it is an important point and that it is true.
And it seems to me that it's too large of an issue to simply overlook. What Sun was thinking about when they made ServletContext not distributable?
This is what I am trying to differ with. IMO, it is not an oversight, but intentional.
Hope I am clear.
- satya
ps:
every time I read this I get a different meaning
:roll:
 
Axel Janssen
Ranch Hand
Posts: 2166
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Agreed.
And: We would have replication conflict problems if changes are propagated.
What if ServletContext on serverA and ServletContext on serverB are changed at the same time? Which change wins?
So. we use JNDI, JDBC or s.th. else. There is more than Servlets/JSP in Java/J2EE.
Axel
 
Gennady Shapiro
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Let me reiterate this:
1. If you setAttribute() in your SerletContext, another user is NOT guaranteed to ever see it -- simply because his objects may be running on another server in the cluster. The server will not synchronize SerletContext across the cluster. (some servers will -- but this is against the spec)
2. I am not sure why you indicated that you may not and must not see SerletContext of another application. Servlet API doc for SerletContext.getContext() says that you can. But I dont really see how its relevant here.
3. If this is not an oversight then how do you explain set/getAttribute methods in SerletContext? we have established that there is no guarantee of visibility for these attributes so why even set them???
This makes no sense to me whatsoever.
 
Madhav Lakkapragada
Ranch Hand
Posts: 5040
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
From what I understand.......
Spec SRV.3.4, SRV.3.4.1 and SRV.3.6, pp 28,29
The getAttribute(...) and setAttribute(...) (and other related) methods are designed to make object attributes, bound to the ServletContext, available to any other servlet that is part of the same web application. They are designed to be local to the VM in which they are created.
Hence your stmt that they are not distributable across all the servers (which have their own local VM's) is true.
Having said that, with reference to your following stmt, I have a comment....
Gennady wrote....
simply because his objects may be running on another server in the cluster

For a ServletContext (application) to run on another server, IMO, it should be identified as distributable in the web-app. If you agree to this stmt, then according to the DTD, pp 93....

The distributable element, by its presence in a web application deployment descriptor, indicates that this web application is programmed appropriately to be deployed into a distributable servlet container.

So Gennady, I agree to the foll. stmt.
"ServletContext cannot be made distributable among various servers running as a cluster by using the getAttributes(...) and setAttributes(...) methods."
Having said that, when you make a servlet distributable, it is the responsibility of the application developer to program correctly. And if a programmer uses getAttribute(...) and setAttribute(...) and is expecting that (s)he can share data among the cluster of servers, then, I will call it inappropriate programming.
For what its worth............
- satya
[ February 25, 2002: Message edited by: Madhav Lakkapragada ]
 
Gennady Shapiro
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Then we are back where we started from. The first line of this thread....According to the spec ServletContext is not distributable. So what's the point of ServletContext.get/setArribute?
 
Madhav Lakkapragada
Ranch Hand
Posts: 5040
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What is your definition of "distributable"?
Thanks.
- satya
 
Axel Janssen
Ranch Hand
Posts: 2166
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Gennadi: If you put for example a JDBC-Connection in ServletContext during HttpServlet.init() in Servlet Life cycle and you just read that value during the application and you dont change that value it makes perfect sense to use ServletContext even in distributed apps (application runs in different VMs).
Or am I wrong?
Axel
 
Madhav Lakkapragada
Ranch Hand
Posts: 5040
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
it makes perfect sense to use ServletContext even in distributed apps (application runs in different VMs).

ummmm...it doesn't make sense to me.
Since if it is a distributed app and runs in different VM's, the attributes will/should/must be different. Each VM, IMO, will have its own ServletContext.
- satya
 
Gennady Shapiro
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Axel, first I thought caching connections in context was a good example -- but then I realized that it should not be done for the following reasons:
1. You use up as many connections as you have server instances, so you use up connections to database and may not use them for long time wasting the resource or you may have many clients hitting it creating a synchonized bottle neck.
2. You dont get life cycle management of objects (connections) that is provided by servers.
3. With init()/destroty() If your DB goes down your connection becomes stale you are stuck with it. (funny, i was just fixing this problem yesterday at work).
4. Web apps have resourse references, ejb references , etc that can be configured in DD explicitely for this purpose.
etc, etc,...
I do however except your idea of caching 'something' in ServletContext, something that does not have to be there but nice to have. Good example, thanks.
Maybe, they meant ServletContext to be something of a global scratch pad...
Madhav, my definition of distributable of ServletContext in this case is synchronization of its state across all servers (VMs) in a cluster, just like Session objects are distributable and synchronized. In case of ServletContext this does not happen. By the way, the distributable attribute of Web DD is not even used by most advanced servers.
 
Madhav Lakkapragada
Ranch Hand
Posts: 5040
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Madhav, my definition of distributable of ServletContext in this case is synchronization of its state across all servers (VMs) in a cluster, just like Session objects are distributable and synchronized. In case of ServletContext this does not happen.
It is NOT intended to happen by design according to Servlet SPec 2.3.
By the way, the distributable attribute of Web DD is not even used by most advanced servers.
Are we still talking of "servers" that implement Servlet Spec 2.3.......just curious.
If so could you name some of these "advanced servers". Thanks.
regds.
- satya
 
Gennady Shapiro
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That is correct!!! That ServletContext's behaivior described by spec 2.3 is not distributable! The whole question the wont let me sleep at night is why! Why the hell not? No explanation. This is what we are trying to understand here, why did they make it not-distributable. And I am willing to bet that they will do it in say ... version 4.0.
Second part of the question. Yes, some servers such as Weblogic 6.1 that implements servlet spec 2.3 does not make use of Web app DD element <distributable>. That is stated explicitely in their docs.
 
Axel Janssen
Ranch Hand
Posts: 2166
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Wouldn't that synchronization not slow down the application in a considerable way?
Axel
 
Gennady Shapiro
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Doesnt session synchronization slow things down? I would imagine your average web app does a lot more session attribute manipulations than context, right?
Although, you do make a good point. Normally, you synch your primary session object with the secondary session -- only one, regardless of how many servers are in the cluster. With, ServletContext you would have to synchronize its state across ALL servers in the cluster...imagine something like Amazon having to synchronize 500 servlet contexts every time one of them updates context ...maybe thats the reason they dont make it distributable. That actually makes sense.
 
a aaaa
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Gennady Shapiro,
I have the exactly same idea with you!!!
Personally, I think this is a defect. Oracle 9iAS is one of the servers which "fixes" the problem. Oracle9i Application Server Java2 Enterprise Edition Facilities and Design Considerations
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic