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]
