>>> Mark Foley <[EMAIL PROTECTED]> 23-Jan-00 10:57:07 PM >>>
>Can anybody out there answer me this? I asked this last week,
>and apologise for asking again, but I haven't been able to find
>the answers myself. Perhaps it's too hard to answer?
I saw this last week... it's really a question for the websphere guys
coz this stuff is implementation dependant.
However....
>On Win NT Server, We are using IBM WebSphere 2 Standard Edition,
>which I believe uses a single JVM on which to run the servlets.
That
>means our static synchronized methods are really single threaded,
Yup.
>and no two two servlet sessions can use a static synchronized method
>simultaneously.
Yup again.
>If we were to use a servlet engine like WebSphere Pro edition, which
has
>four JVMs if memory serves, would we be able to see an up to four
times
>simultaneous use of static synchronized methods (and safely)?
It seems to me that this would be possible in theory but it may not
be safe.
Firstly sessions: If you have a centralised session management system
then by definition you must lock updates to session data when in a
multi-process environment (to avoid possible corruption).
Sync methods: If you're concerned about the ability to call synced
methods from your session stored objects then it would seem likely
that contention does not apply, only to an object being stored across
VMs (with some sort of data synchronisation). Therefore you should be
able to run simultaneous threads (on different VMs) in those methods.
Static methods: maybe different again because of where and how the
VMs may choose to store/share them.
As I say... the best bet is to go straight to websphere team unless
someone else can help with this?
>Further, we are using the JNI to access a third party product which
only
>allows a single thread to be using it per NT Process. Would four
JVMs map
>to four NT processes?
Or four NT threads yes but again it's implementation dependant -
witness how many different variations Sun provide threads in the
classic JVM.
>Further still, can we be sure a single JVM will be assigned to a
particular
>session for its lifetime?
I doubt this very much. If I was the developer of a shared session
system I wouldn't want to gaurantee anything about the precise
location of the session. A certain level of abstraction from the
physical norms comes with the territory.
>Thanks for any answers to these question!
I'm not sure these answers are any good... but it might spark some
debate. It's an interesting subject and I'm sure a discussion of these
problems could further distributed session servlet-container
implementations.
Nic Ferrier
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
