a connection. I've become rather superstitious about this but
I think it is a good idea. If you are writing code that can be called
from anything- IE 5.0, NS6, or a test application- you don't really know
when you are inviting deadlock or freezing a UI. I think you get better
modularity by doing anything critical with a thread you have complete
knowledge
of rather than hoping you don't get deadlock in some situations. I did
have one
case of an applet locking up ( sporadic, never fully tracked down) by
putting in (what I thought) was a safe synchronized block in a method
called
by JavaScript. Obviously, this depends on what you are trying to do- if
the
caller needs to block, then it needs to block.
I was hoping someone else could qualify my statements...
I hereby state that, to the best of my knowledge and belief,
the foregoing statements are, or could potentially be, relevant to
Servlets.
Thanks.
-----Original Message-----
From: Hugo Malheiro [mailto:[EMAIL PROTECTED]]
Sent: 2001,September.24.Monday 11:08 AM
To: [EMAIL PROTECTED]
Subject: Re: java.net.ConnectException in applet connection to servlet
When you say "workaround" do mean using something like described in
http://www.kfki.hu/~cspeter/jvm-bugs/ns6jsace.html . Can you explain me
what
this prevents? advantages?
-----Original Message-----
From: A mailing list for discussion about Sun Microsystem's Java Servlet
API Technology. [mailto:[EMAIL PROTECTED]]On Behalf Of Mike
Marchywka
Sent: segunda-feira, 24 de Setembro de 2001 14:15
To: [EMAIL PROTECTED]
Subject: Re: java.net.ConnectException in applet connection to servlet
In general, I don't think it is good practice to do anything from
a JavaScript or event thread except set a flag. Any comments?
You simply don't have a lot of control over these unknown threads
or what they are doing or locking. It is probably not very safe to
This message was posted using eunum
To interact with a real-time, threaded interface to this e-mail list, clickthe link below:
[EMAIL PROTECTED]
