Joerg,
Thanks, it does answer my questions, and raises a few others. I'm
heartened by this, because what you have described is the inappropriate
use of global data in a multi-threaded context. I'm interested because
I like statics. They are smaller and faster; what's not to like?
Before continuing with them, though, I need to make sure that I
understand the problems.
The scenario you describe is a doomed attempt to globalise local data.
However, there are times when some initialization of truly global data
is required, yet it cannot be accomplished with static{} blocks. What's
needed is a one-time initialization method. This can be synchronized.
Protect the initialization method or some initialization object, and
set a flag within the method to declare that the job is done. Test this
on entry, after synchronization. Because none of the processes which
require the data will attempt access until after init, access itself
does not need to be synchronized. (I'm assuming here that all statics
are global relative to the JVM.)
It seems to me, of what I have heard so far, that there is no problem
with statics _per se_. If they are used with an awareness of the
possibility of multi-threading, they should present no special
difficulties. I have heard it said, though, that statics are forbidden
in EJB environments. Is this true? If so, what are the special
constraints that apply to EJBs?
Regarding configuration in FOP, it is interesting to note that there are
two different config hierarchies depending on whether the environment is
uniform, as, e.g., in a single thread, or diverse, as in the example
Arnd offered. (That is, a separate process constructs stylesheet
information and other variables into an instance-specific storage
location, and invokes a fop thread with a reference to that location.)
In the first case, the config hierarchy is:
system config
user config
command line
despite the fact that the user config file may be specified on the
command line. Other data from the command line will override
assignments in the user config (else why specify them?)
In the second scenario, the most instance-specific data is in the user
config file (if that is being used to pass the instance data) or in some
other instance-specific config source. So the hierarchy looks like:
system config
command line
user config
or
system config
user config
command line
instance config
I like the second idea better.
Not knowing a great deal about JVMs and class loaders, I'm curious to
know how dynamic data can be introduced into threads started within a
pre-existing JVM. One solution of Arnd's problem would seem to be to
control the process of setting up the FOP thread configuration
subdirectories from within the JVM, and allow for new FOP objects to be
initialised with this information. That is not a general solution ot
the problem though. How is it usually done?
Peter
J.Pietschmann wrote:
> The problem is multiple threads accessing static class data,
> which is really global.
> Well, the standard scenario is: There are multiple threads
> sleeping while waiting for requests. One thread wakes up,
> sets the FOP baseDir, creates a Driver instqance and starts
> rendering. Just before the thread is about to resolve an URI
> for an external graphic, it is suspended and another thread
> gets a chance to run, it reads its request, sets the global
> baseDir to soemthing else, and is itself suspended in favour
> for the first thread, which reads the now changed value for
> baseDir from the configuration, and explodes.
>
> It doesn't help to make the Driver methods synchronized,
> because there are two instances of the driver object :-(
> you would have to lock the global configuration data so
> that the second thread would have to wait until the first
> finishes processing. Of course, this nullifies the advantages
> of using multithreading, especially on MP machines.
>
> I like the approach JAXP did for transformers. You have
> a factory where you can set default stuff so that you
> don't have to do this every time an individual processor
> is created, and you can override settings on the individual
> instances. The individual processor instances never access
> global data after creation.
>
> Does this answer your question(s)?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
