Okay, I'm sold. Leave it alone and wait until someone files a Jira issue with a stack trace! :-)
-----Original Message----- From: Achim Hügen [mailto:[EMAIL PROTECTED] Sent: Thursday, June 08, 2006 6:16 PM To: [email protected] Subject: Re: Double proxies vs. synchronization This reminds me very much of the discussion about the 'double checked locking' pattern. Although there was the claim that it is broken it was a highly theoretical discussion. As far as I know no one ever proofed that claim on a modern jvm (> 1.1). For example a simple question has never been answered: What kind of exception occurs if an "not fully instantiated" class is called? I severly doubt that any test scenario will proof the synchronization problem. And if any user will ever have this problem there is an easy work around: eager load the service and call some method on it. Achim Am Thu, 08 Jun 2006 20:06:12 +0200 schrieb Howard Lewis Ship <[EMAIL PROTECTED]>: > The discussion at: > http://howardlewisship.com/blog/2006/06/whoa-spring-doesnt-lazily-instantiat e_05.html > > has pointed out that, quite possibly, HiveMind has synchronization > problems > w.r.t. instantiating services. > > I'm not completely buying it. Looking at the code paths, it seems > unlikely > to me that the compiler would have much opportunity to inline things. > > Insidethe inner proxy (generated by SingletonServiceModel) we see the > following code: > > private final synchronized MyServiceInterface _service() > { > if (_service == null) > { > _service = (MyServiceInterface ) > _serviceModel.getActualServiceImplementation(); // 1 > > _deferredProxy._setInner(_service); > // 2 > } > > return _service; > } > > The memory model for Java is a tricky thing in concurrent code. > > The first line of code (// 1) may not completely execute before (// 2) > does. > That leaves a tiny window where _service is not fully instantiated and > yet > is exposed (via the OuterProxy, aka _deferredProxy) to some other thread. > Further, the nature of these two statements means that //2 can't happen > before //1, just in parallel. It's a pretty damn tight window. > > Personally, I don't see it. If (// 1) was just creating a new instance, > there might be something. However, getActualServiceImplementation() does > a > lot of work, much of it delegated to other objects. The secondary objects > (service and interceptor factories) are hidden behind interfaces, > interfaces > with multiple implementations (and therefore, not likely to be inlined by > the magic of Hotspot). The window shrinks from merely remotely possible > to > zero. > > Further, the scenarios necessary for even the remotely possible window > are > not completely likely. If multiple threads all hit _service() at the same > time, they will be serialized by the synchronized lock on the method. > What's > necessary is that, while //1 and //2 are both running, yet another thread > arrives inside the OuterProxy and sees the full service implementation > (via > //2) before the initialization code (// 1) finished executing. > > I'd love for every bit of code I write to be provably correct under any > circumstances. For this to be an actual concern, we'd need the > intersection > of many different unlikely scenarios to line up: the threads arriving > inside the OuterProxy and InnerProxy at just the right times (highly > unlikely) along with Hotspot reording the code (distributed across at > least > a dozen different classes) so that //2 occurs before //1 completes. > LIkelyhood falls close enough to zero to not be an issue. > > I really like the fact that, once the service implementation is fully > instantiated, the inner proxy goes away, and the outer proxy can > delegate to > the service implementation without needing any synchronization. > --------------------------------------------------------------------- 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]
