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 only instantiated once.
That would be an interesting research project, a JVM that runs inside a virtual hyper-multicore system. That is, a simulation of a, say, 1000 core workstation, used to flesh out synchronization problems that won't manifest inside single or dual-core CPUs. On Nov 17, 2007 9:40 PM, Ben Tomasini <[EMAIL PROTECTED]> wrote: > 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 scope also created by the > JustInTimeObjectCreator? > > Ben > > > > > On Nov 17, 2007 6:21 PM, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > > 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 "publishes" the dependencies so > > that a different thread using the same instance will not be > > encumberred. > > > > Other threads may inject the service's proxy or may be waiting to > > invoke methods on the proxy (there's a traditional serialized method > > that guards the latter). > > > > The central mutex is really used to handle very exception case: two > > different threads, each constructing a different service, each of > > which invokes a method of a shared dependency, all simultaneously. > > The sun will have cooled to a cold cinder before that actually happens > > in production. > > > > > > On Nov 17, 2007 4:47 PM, Ben Tomasini <[EMAIL PROTECTED]> wrote: > > > 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 supported, allowing setter injection to be done as well? In > > > such a case, what measures does Tapestry IoC take to ensure that while > > > a service is being created lazily on thread A, thread B does not get a > > > partially constructed object (a la double checked locking)? After > > > reading Brian Goetz's book, I am starting to wonder if that is even > > > possible without final instance variables or full synchronization on > > > the registry. > > > > > > Ben > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > -- > > Howard M. Lewis Ship > > Partner and Senior Architect at Feature50 > > > > Creator Apache Tapestry and Apache HiveMind > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Partner and Senior Architect at Feature50 Creator Apache Tapestry and Apache HiveMind --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
