From: Werner Donné (werner.donne@re.be)
Date: Mon Oct 28 2002 - 07:00:24 PST
David,
> None of the options that may be required to set differently within one VM are
> in fact set by environment variables. Everything you may want to set differently for
> different threads of XEP can be set using API variables and calls.
>
> System properties are for providing DEFAULT values. Exactly the same way as, for example,
> org.xml.sax.parser.
This reassures me, because it is my main concern.
> Generating temporary files in tmp for application programs in a multi-user machine is
> a bad practice anyway and is a source for many security risks. On the other hand,
I agree with the security argument. However, one non-human account can be used for
running the application servers. That is in fact how we do it. This account is not
accessible for regular users. It contains all the resources the application servers
use, including temporary directories. In such a situation sharing a temporary directory
doesn't bear additional security risks.
> simply wrapping XEP in a script that looks like:
>
> #!/bin/sh
>
> TMPDIR=/tmp/xep/$USER/$$
> mkdir -p $TMPDIR
> java -Dcom.renderx.xep.TMPDIR=$TMPDIR com.renderx.xep.Driver $*
> rmdir $TMPDIR
We could indeed add this to the launch scripts of our application servers.
> There is no solution to the problem of generation of unique file names within Java API across
> JVM boundaries.
This is rather theoretic. The File.createTempFile method guarantees that when it returns
successfully, the file it returns did not exist before calling the method. What can
happen is that the method fails, because the file already exists. If the time, expressed
in milliseconds, is used together with a random number and if a retry loop is run,
the chances for a collision are very small. The number of iterations of the retry loop
is in theory infinite if there is more than one CPU in the machine, because two or more
threads could be scheduled in the same millisecond doing exactly the same thing. With
one CPU, two threads couldn't be scheduled in the same millisecond.
The retry loop is in fact a race for a concurrent resource. It is no different from a
race for a semaphore for example. The loop will very rarely iterate more than once.
Werner.
-- Werner Donné -- Re BVBA Engelbeekstraat 8 B-3300 Tienen tel: (+32) 486 425803 e-mail: werner.donne@re.be ------------------- By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/tos.html
This archive was generated by hypermail 2.1.5 : Wed Dec 18 2002 - 08:41:28 PST