Thanks Umit. Indeed we do that too. We have a ServiceLocator supertype which all of our concrete ServiceLocator concrete subclasses extend, and isLive() is implemented to unconditionally return true in that implementation.
Thanks, Doug On Monday, November 4, 2013 1:31:28 AM UTC-8, Ümit Seren wrote: > > If you don’t care about EntityChangeEvents you can also override the > isLive() method and return true (see > here<http://stackoverflow.com/questions/9476341/requestfactory-theory-why-is-locator-find-being-called-so-often> > ). > This improved performance quite a bit at least in my case. > > On Friday, November 1, 2013 1:20:14 AM UTC+1, Doug Gschwind wrote: > > Hello everyone, >> >> We are using GWT 2.5.1, Hibernate 4.x as a JPA 2.x provider, Oracle >> database 11g, and RequestFactory for our application. One of the areas of >> our application is slightly slow at read time and is noticeably slower at >> write time. The use case in particular is a fairly complex editor where the >> read part of the puzzle is used to render the complex UI and the write part >> of the puzzle is used to save end user edits made in this complex editor >> UI. In this particular use case, we use RequestFactory. In other areas of >> our application we have some GWT-RPC in use, but we are migrating away from >> its use in favor of using RequestFactory. >> >> In our RequestFactory use, we use the ServiceLocator pattern and our >> ServiceLocator's unconditionally return true from isLive(), for background >> information. We are not using the Editor framework in this area of the >> application. >> >> We have been working on this set of use cases some time and are quite >> comfortable with the Domain Model that we have in place, which to simplify >> looks like the following : >> >> class A >> | >> -- class B >> | >> -- class C >> | >> -- class D >> | >> -- class E >> | >> -- class E1 >> | >> -- class E2 >> | >> -- class E3 >> >> There are OneToMany relationships between the following classes : A -> B, >> B -> C, C-> D, D-> E, E -> E1, E -> E2, E -> E3, with back pointing >> ManyToOne relationships throughout. Each of these classes are not >> transportable, in the RequestFactory sense, so we have an EntityProxy for >> each class. >> >> When an end user saves their edits, lots of db query traffic can be seen, >> which appears to be due to hydrating the entire graph of objects and >> stitching them together. I suspect that we could reduce the system response >> time of the save/write use case if all of this ServiceLocator find() >> infrastructure was subverted since once we read/find the A instance, it can >> be used to apply all edits without a find() call per node in the graph. >> >> Have any of you faced this type of problem and were you able to find an >> implementation alternative which proved faster by using maybe GWT-JSON or >> GWT-RPC or some other means? >> >> If you got here, thanks for reading and your replies in advance. >> >> Doug >> >> > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out.
