I am using Restlet 2.1.2 on Google App Engine and I am thinking about its thread safety. <threadsafe> is set to true in my GAE's configuration.
In general, there are concurrency notes in the documentation for some classes e.g. ServerResource class is thread-safe and a new instance is created for each caller thread. This means, that I can safely store state in member variables (e.g. parameters from the request URL). Further the Filter class is not thread safe and one object of this class can be called by multiple threads at once, so the state cannot be saved in member variables and something like ThreadLocal can/should be used.
Further, all Authenticator sub-classes are not tread safe because they are sub-classes of the Filter. Authenticators use a Verifier to verify login credentials and there is no concurrency note in the documetnation for the Verifier classes...
My questions are:
1) Can I safely store some state in a Verifier sub-class or I must use something like ThreadLocal? I think that the second option is true. ...I want only one Datastore read to get a user account and later create a User instance based on this info. I am subclassing a SecretVerifier.
2) Is there somewhere an example/article with information about these multithreading issues in Restlet in one place and not only scattered in the documentation? At least information about classes which have on instance per caller thread and which instances are shared among multiple caller threads would be great.
First, let me clarify that the whole Restlet API has been designed to be used by concurrent threads.
Most classes (especially subclasses of org.restlet.Restlet) are designed to allow instances to be shared by multiples threads concurrently and therefore those classes must be thread safe, in the sense that if they share variables between those threads it must be via final or volatile fields of thread safe classes (Concurrent* classes).
Otherwise, it is always possible to store information in the Request/Response objects themselves, especially in their "attributes" property rather than going through the thread local variables.
As far as I remember, only Resource subclasses are designed to be called by a single thread at a time, but note that you might still have to deal with thread visibility issues.
Hope this clarifies.