It's only one instance that can be accessed by all sessions, this
attribute is not synchronized, it works this way

Thread Loads camera's image (contents) into the servlet context as
attribute.
User sessions (servlet instances) can access this attribute by HTTP
request to display in the browser.

My question is, if there are limitations to access servlet context
attribute other than hardware resources, I have Dual processors 3.06,
and 2GB RAM, SCASII drives, win2003 server

1GB of memory is reserved for Tomcat.

 

-----Original Message-----
From: Ralph Einfeldt [mailto:ralph.einfeldt@(protected)]
Sent: Wednesday, April 28, 2004 15:01
To: Tomcat Users List
Subject: RE: how many sessions can read the ServletContext() at a time


Sorry, that doesn't answer my question.

Is the video the same in each instance ?

If it is, you need just one instance of the video
that is accessed by all servlets. In this case the
costs to access the video are quite low compared
against the cost to write the stream. So it's most
likely the later that will limit your concurrent
sessions.

You won't get any estimates from me, you have to
test with your environment and your application. In
my exprience these factors have much more effect on
the performance than tomcat itself.

> -----Original Message-----
> From: Futchi [mailto:msafadi@(protected)]
> Sent: Wednesday, April 28, 2004 3:44 PM
> To: 'Tomcat Users List'
> Subject: RE: how many sessions can read the ServletContext() at a time
>
> It is live optimized video, each session updated every one second, the
> only shared place between all sessions is the "servlet
> context" where I
> have to transfer the image into (using java servlet Thread). Then each
> session can be updated every one second from the "servlet context",
> memory location is always faster and more reliable than using files or
> DB.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
For additional commands, e-mail: tomcat-user-help@(protected)




---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
For additional commands, e-mail: tomcat-user-help@(protected)