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]
