Yeah. If I know that I'm going to hit shared services that aren't
purely stateless, then I will tend to use a worker that spawns a
thread, which can be polled from time to time. I wrote a nice little
wrapper infrastructure for this, so I basically just override the "do"
method and then th
The good news is that the synchronized keyword is getting really cheap
so code that gets distorted trying to avoid synchronized should just
code it up simply. Then there's the 1.5 concurrency support, which is
fantastic. Brian Goetz has talked about an arms race between the VM
guys and the concur
I've usually found my race conditions, or stupid multi-threading
mistakes with 2 processors just fine. I'm just trying to wrack my
brain to find one that would be solved with 3+ that wouldn't be found
with 2. Hmmm...
Christian.
On 19-Nov-07, at 12:49 AM, Howard Lewis Ship wrote:
It's
It's not deterministic at all and that's the scary part. Another
option would be to create a virtual multi-core computer that exists to
force unlikely but valid race conditions, to ensure that they are
handled properly. But I'm anything but an academic.
On Nov 18, 2007 12:39 PM, Christian Edward
Wouldn't you get proper multiprocessing behaviour from a dual-core
processor, since the choice of processor that is accessing a given
thread at any point isn't deterministic, nor is thread execution
order? Or would you just find the issues faster on 1000 processors.
christian.
On 18-Nov-0
For "perthread", the JustInTimeObjectCreator ends up creating the
per-thread proxy for the service. The per-thread proxy deals with
creating a per-thread realized instance and cleaning it up at the end
of the request (thread cleanup phase). Interceptors go around the
per-thread proxy, so they are
Thanks for explaining this. Let me see if I have it right:
The MUTEX in ModuleImpl guards the creation of the service proxy, and
the synchronized method in JustInTimeObjectCreator guards the actual
creation of the object when the service is "realized". (?) Are
objects for services with perthread
There is a single mutex used for all service construction. As I
understand thread safety, this should be sufficient. The building
thread will invoke the builder method and from there, the service
constructor. The dependencies are provided and stored in final
instance variables (ideally). This "p
I understand that constructor injection and final instance variables
are the preferred way to do dependency injection with Tapestry IoC.
This is clearly safest in terms of proper, thread-safe construction
and immutability.
Am I correct in assuming that good ol' build* methods on modules are
still
