Hi,
On Fri, Jun 28, 2013 at 12:43 AM, Bas Gooren <b...@iswd.nl> wrote: > Hi Andreas, > > My guess is that the GuiceComponentInjector proxies are "detached" when > the page is serialized. > The last page (or the last N pages) are kept in memory by wicket (I think, > last I checked was some years ago). > > Checking ... > Yes, see LazyInitProxyFactory and its nested class JdkJHandler (which is > used for injected interfaces). > The proxy is replaced on serialization. > > Somehow I always thought the proxies were also detached when the page is > detach()-ed. Guess not :-) This explains it! The last used page instance is stored in the HttpSession, and this keeps a reference to a proxy with a closed EntityManager. Wicket detaches all components and their default models, but there is no logic to null-ify the transient field in JdkHandler - https://github.com/apache/wicket/blob/master/wicket-ioc/src/main/java/org/apache/wicket/proxy/LazyInitProxyFactory.java?source=c#L375 The simplest solution is to not keep the 'target' as a field at all. Just as the IProxyTargetLocator for the service at every usage. Will this be slow ?! > > Met vriendelijke groet, > Kind regards, > > Bas Gooren > > Op 27-6-2013 23:37, schreef Andreas Lundblad: > > On Thu, Jun 27, 2013 at 11:25 PM, Bas Gooren <b...@iswd.nl> wrote: >> >>> Hi Andreas, >>> >>> When your validator fails, you remain on the FormPage. A quick debug >>> session >>> shows me that the injected IService remains the same accross requests. >>> >> I've seen this too. I thought that this didn't matter since, as you >> said: "The GuiceComponentInjector which is set-up in the wicket >> application injects proxies". >> >> The fix for your problem is simple, and a best practice anyway: inject >>> Provider<EntityManager> in your service. >>> >>> It's a best practice since the service does not know the "scope" of the >>> entitymanager, all it knows is that the entitymanager has a different >>> lifecycle; Your service may be instantiated and kept around for the time >>> your app is running, but could also be instantiated on the fly when >>> needed. >>> That's one of the reasons why Provider<> was invented: if the scope is >>> different, a provider allows you to nicely deal with it. >>> >>> In case you are not familiar with providers: it has no negative >>> side-effects >>> in terms of performance. >>> The guice-persist module binds the EntityManager per request, so all >>> calls >>> to Provider<EntityManager> while in the same request will yield the exact >>> same EntityManager instance. >>> >>> >>> >>> PS See https://code.google.com/p/**google-guice/wiki/** >>> InjectingProviders<https://code.google.com/p/google-guice/wiki/InjectingProviders>(header >>> "Providers for Mixing Scopes"). >>> >> Thank you Bas for this excellent answer. Much appreciated. >> >> -- Andreas Lundblad >> >> ------------------------------**------------------------------**--------- >> To unsubscribe, e-mail: >> users-unsubscribe@wicket.**apache.org<users-unsubscr...@wicket.apache.org> >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >
