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


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?


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]

Reply via email to