From: David Tolpin (dvd@renderx.com)
Date: Mon Oct 28 2002 - 07:15:26 PST
Werner,
>
> 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
This method is not present in JDK 1.1.8, which (that is, MS Java implementation) XEP still
supports.
> 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.
A much simpler and straightforward solution than trying to pursue file
system's and random numbers generator's percularities is to pass a unique
identifier _to_ each instance of JVM. This is what TMPDIR variable
is for. It may be easily accomplished via passing, say, JVM process
identifier (number) as a part of TMPDIR variable's value.
Instead of creating a function that is good enough for creating really unique file names
and then dealing with deadlocks and lost files just because something has been left out
and turned out to be significant, I recommend to employ a simple and straightforward approach.
Taking into consideration that:
1. An instance of JVM cannot uniquely identify itself.
2. An operational system that runs a JVM can uniquely identify each of the running JVM.
It is proposed that
A unique identifier is not generated inside JVM but is passed to the JVM by the operational system.
The simplest way in many OSes is to pass JVM's process identifier. Other options, such as locking
a file system file and incrementing a counter stored in it or creating a special device, are also available.
I don't see how it is different from the need to prevent XEP from writing to the same output file.
David Tolpin
RenderX
-------------------
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